AXP-Resurection/docs/009-fortify-boot-audit-20260926.md

FORTIFY: auditoría del build 20260926T183144Z

Revisión de solo lectura en rom-dev01. Sin compilaciones ni flasheos nuevos. El dueño confirma arranque de ksync-slab y fallo del último FORTIFY.

Artefactos y empaquetado

Raíz remota: /srv/rom/artifacts/009-axp-los23-port/.

• Referencia: 20260926T171215Z-bisect-ksync-slab-only.
• Fallido: 20260926T183144Z-bisect-ksync-fortify-only/boot-make.img.
• SHA-256 registrado del fallido: 89734e6a34f99bfdc2d334e06e1ff49da46dac311139b7dc54f25ae7af0f0641.
• Ambos ramdisks desempaquetados tienen SHA-256 c9ebabdcec875c896530214c5f2988e30a6bc37754855e4cba4863692d7db519.
• Ambos DTB tienen SHA-256 2fca15709ff6d9f48fea938952439e8d00c2b998c73e7a216172ae3965b07566.
• El header del FORTIFY conserva Android 16 y parche 2026-09.
• El script usa breakfast y exige TARGET_RELEASE=bp4a.

El problema anterior de cambiar la release/ramdisk no aparece en esta comparación. La config embebida del fallido tiene FORTIFY=y, SLAB_FREELIST_HARDENED=n; la referencia slab tiene las dos opciones al revés. Ambos conservan LTO y CFI.

Hallazgo principal: la exclusión de Clang es ineficaz

En /srv/rom/src/lineage/kernel/google/msm-4.14/security/Kconfig:190-195:

config FORTIFY_SOURCE
    bool "Harden common str/mem functions against buffer overflows"
    depends on ARCH_HAS_FORTIFY_SOURCE
    # https://bugs.llvm.org/show_bug.cgi?id=50322
    # https://bugs.llvm.org/show_bug.cgi?id=41459
    depends on !CC_IS_CLANG

git grep no encuentra una definición de CC_IS_CLANG en ese árbol. La config generada tampoco contiene CONFIG_CC_IS_CLANG. La restricción usa un símbolo no definido y por ello no detecta el compilador real.

obj/KERNEL_OBJ/include/generated/compile.h identifica Clang 21.0.0, r563880c, LLD 21, no GCC. El commit que introdujo la restricción es eb4c4383950d, «fortify: Explicitly disable Clang support».

Esto demuestra un defecto de integración/configuración. No demuestra por sí solo la instrucción concreta que provoca el fallo de arranque. Un Clang más nuevo no sustituye automáticamente las adaptaciones del código FORTIFY.

Referencia primaria de las adaptaciones upstream: Kees Cook, fortify: Add Clang support, v7 8/8. La serie adapta wrappers y atributos de tamaño de objeto; no consiste en añadir cuerpos BUG a símbolos sin resolver. El parche AXP 0008-Graphene-Kernel_Hardening-fortify/4.14/0004.patch, inspeccionado, añade comprobaciones intra-object; no aporta por sí solo ese soporte Clang.

Segundo defecto: el error de enlace se convirtió en código ejecutable

Primer intento, log remoto /srv/rom/artifacts/detach-009-bisect-ksync-fortify-20260926T172516Z.log:

ERROR: "__read_overflow2" [techpack/audio/dsp/q6_dlkm.lto.ko] undefined!
ERROR: "__read_overflow" [drivers/staging/qcacld-3.0/wlan.lto.ko] undefined!

El script scripts/009-bisect-ksync-one.sh añade después a lib/string.c cuatro funciones exportadas (__read_overflow, __read_overflow2, __read_overflow3, __write_overflow) con cuerpo BUG(). Así consigue enlazar, pero no resuelve por qué el compilador emite llamadas a esos helpers, declarados para diagnóstico en include/linux/string.h:241.

El objeto generado techpack/audio/dsp/q6_dlkm.ko, desensamblado, contiene:

rtac_remove_voice + 0x1d0, offset 0x673ec:
R_AARCH64_CALL26 __read_overflow2

El código asociado incluye la copia de elementos en shift_voice_devices (techpack/audio/dsp/rtac.c:638-644). Falta resolver si el diagnóstico indica un acceso real fuera de límites o un problema de los wrappers/compilador. No convertirlo en un no-op ni aceptar BUG como solución.

Límite importante: el ensayo despliega solo boot y conserva los módulos vendor previos. Esta llamada existe en el módulo recién compilado, pero no se ha demostrado que ese módulo se cargue en LAB. Tampoco se encontraron llamadas directas desde funciones ordinarias de vmlinux a los cuatro stubs en la búsqueda realizada (sí sus entradas CFI y sus bucles internos). Por tanto, no se atribuye el fallo de arranque específicamente a ese stub. Las llamadas normales a fortify_panic son parte de FORTIFY y su presencia no prueba que ninguna se ejecute durante el arranque fallido.

Siguiente paso justificado

1. Conservar ksync-slab como referencia que arranca. No encadenar más opciones sobre el build FORTIFY fallido.
2. Tratar FORTIFY como un port con dependencias: estudiar la implementación AXP y adaptar soporte Clang al kernel 4.14, incluyendo detección de compilador y pruebas de los wrappers. Corregir la detección sola bloquearía esta opción; no equivaldría a implementar FORTIFY.
3. Retirar los stubs BUG de la receta candidata y resolver los diagnósticos de audio/WLAN, validando la causa de cada llamada. Mantener LTO/CFI como referencia; desactivarlos globalmente introduce otra variable y pierde protecciones ya funcionales.
4. Archivar .config, diff, vmlinux y Module.symvers por build. Comprobar compatibilidad con los módulos realmente desplegados, no solo uname.
5. Obtener una traza del intento fallido que distinga FORTIFY, CFI, carga de módulos y montaje de datos. En esta revisión ADB no detecta teléfonos, por lo que no se han leído registros actuales de LAB.

Conclusión: hay un defecto concreto de habilitación y un arreglo de enlace inadecuado. La causa exacta en ejecución sigue pendiente; no anunciar otro boot como reparado únicamente porque vuelva a compilar.

Plan de port (siguiente documento): docs/009-fortify-clang-port.md.

Logs LAB post-fallo (2026-09-26, Cursor)

Teléfono en fastboot tras FORTIFY. Reflasheo slab-only (boot_a/boot_b) y reboot. /sys/fs/pstore/ vacío (0 ficheros); sin console-ramoops ni last_kmsg. Misma ausencia de traza que en hangs Stage1/CVE previos. No hay dmesg del intento fallido. Artefacto local vacío: .local-artifacts/009-fortify-crash-20260926/.