# Revisión del port FORTIFY en curso — 2026-09-26, 21:25 UTC

Revisión de solo lectura del servidor; no se han editado scripts en ejecución.
El dueño confirma combo4 arrancado. Cursor registra kernel #16, DMESG,
SLAB_FREELIST_HARDENED, INIT_ON_ALLOC y INIT_ON_FREE activos, FORTIFY apagado.
No se ha repetido aquí la inspección de LAB.

## Estado real

Job: `009-bisect-ksync-fortify-clang`, iniciado a las 21:15:03 UTC.
Log: `/srv/rom/artifacts/detach-009-bisect-ksync-fortify-clang-20260926T211503Z.log`.
A las 21:25 UTC seguía activo, con procesos clang consumiendo CPU. El log
principal no se actualizaba desde las 21:18:39; eso no implicaba bloqueo.
No había resultado final ni nuevo artefacto FORTIFY validado.

El script recibe **solo CONFIG_FORTIFY_SOURCE**. Es un ensayo aislado, no
combo4+FORTIFY; coincide con el plan local. Preserva breakfast/bp4a y el
empaquetado sobre GOODMAKE. El diff actual no modifica lib/string.c ni añade
los stubs BUG. Mantener deshabilitado ALLOW_FORTIFY_BUG_STUBS.

## Hallazgo que revisar antes de aceptar el port

El script `apply_fortify_clang.py` adapta atributos y prototipos, pero deja
consultas de tamaño incoherentes con algunos atributos:

- POS equivale a `pass_object_size(1)`.
- `strlen` y `strnlen` reciben p con POS y consultan
  `__builtin_object_size(p, 0)`.
- `strlcpy`, `strncat` y `strcpy` reciben q con POS y consultan su tamaño
  con tipo 0. En otros wrappers, POS0 sí coincide con las consultas tipo 0.

Esto no es un detalle estético. La información de tamaño implícita depende
del tipo. Se compiló por stdin una prueba pequeña con el mismo Clang
r563880c, también para AArch64 freestanding, sin escribir en el servidor:

```c
typedef __SIZE_TYPE__ size_t;
__attribute__((noinline))
size_t mismatch(const char *const p __attribute__((pass_object_size(1)))) {
    return __builtin_object_size(p, 0);
}
__attribute__((noinline))
size_t matched(const char *const p __attribute__((pass_object_size(0)))) {
    return __builtin_object_size(p, 0);
}
```

El IR optimizado de mismatch devuelve -1 (tamaño desconocido); matched
devuelve el argumento implícito de tamaño. **Límite:** es una prueba aislada
noinline del mecanismo, no una demostración de que todas las llamadas a los
wrappers always_inline reales pierdan protección. Es necesario probar los
wrappers reales con optimización/LTO, tamaños conocidos y desconocidos.

Referencia primaria:
[Clang: pass_object_size](https://clang.llvm.org/docs/AttributeReference.html#pass-object-size-pass-dynamic-object-size).

Adaptar coherentemente los atributos y la semántica de tamaño del 4.14;
no sustituir todas las consultas por tipo 1 a ciegas, porque cambia la
política whole-object/subobject y puede alterar accesos válidos del árbol.

## Otros puntos de aceptación pendientes

- El port elimina `depends on !CC_IS_CLANG` sin implementar la detección y
  los límites de versión/capacidades que propone su propio plan. Los macros
  de atributos tienen fallback vacío: un compilador no compatible puede
  volver a habilitar un FORTIFY sin soporte. No es prueba de fallo de Clang 21,
  pero la configuración aún no tiene una protección adecuada.
- `__diagnose_as` está definido pero no utilizado en los wrappers revisados.
  Documentar si se omite intencionadamente y validar diagnósticos reales;
  declarar el atributo no implementa su efecto.
- El empaquetador imprime propiedades/config pero varias comprobaciones
  terminan en `|| true`. Mostrar el valor no garantiza que coincida con el
  esperado. Antes de entregar: comparar hashes de ramdisk/DTB, metadatos,
  kernel inyectado y opciones de la config embebida, fallando si difieren.
- No editar el script activo. Congelar copia, hash, argumentos, diff y
  configuración por experimento para evitar repetir el incidente combo4.

## Qué debe probarse además de compilar y arrancar

Sin stubs es necesario, pero no suficiente: quitar accidentalmente una
comprobación también puede hacer desaparecer símbolos de overflow.
Usar casos válidos y desbordamientos intencionados en un harness aislado
de los wrappers reales (no provocar corrupción en LAB), comprobando el
diagnóstico o camino de fallo esperado con Clang/LTO. Verificar también
ausencia de stubs en binarios/módulos, .config efectiva y hardware básico.
Después del ensayo aislado, validar combo4+FORTIFY como artefacto distinto.

Conclusión: el enfoque mejora y el build está activo; aún hay detalles del
port y pruebas de eficacia pendientes. No equivale a un port ya aceptado.