AXP-Resurection/docs/009-fortify-bounds-boot-failure-20260927.md

FORTIFY bounds: enlace correcto, arranque fallido

Artefacto remoto: 20260926T223246Z-bisect-ksync-fortify-bounds bajo /srv/rom/artifacts/009-axp-los23-port/. El dueño informa logo Google, reinicios y finalmente fastboot. El proceso de build terminó exit=0 a las 22:32:52 UTC del 26 de septiembre.

Verificaciones realizadas

• Los dos parches de límites están en las fuentes actuales. Audio/WLAN ya no tienen los símbolos sin resolver __read_overflow* en sus objetos LTO. Sí usan fortify_panic, que el kernel define y exporta normalmente.
• lib/string.c no tiene modificaciones/stubs; vmlinux no contiene los cuatro helpers artificiales de overflow de los intentos anteriores.
• El boot descargado tiene SHA-256 ba5ac99eb2873dac4c3c8b108753bb89e5aa7a7d71972361e32b39f6ed9ef136, igual al registro remoto.
• Desempaquetado local correcto: Android 16, parche 2026-09, header v2. El kernel extraído tiene SHA-256 99348e4f21a46c3bf95dde3a97995cd97375a6792427c5d497b3296fa0c0a906, idéntico al kernel nuevo y al kernel verificado en el servidor.
• Los ramdisks en los directorios remotos work/check del fallido y combo4 tienen el mismo SHA-256. Se conserva el método ksync.

Error ignorado por el empaquetador

El log muestra que el último magiskboot unpack (línea 91 del script) terminó con Illegal instruction (core dumped). El || true permitió continuar y declarar DONE. Es un defecto de verificación que debe corregirse. No demuestra que la imagen sea inválida: la copia con el mismo hash se ha desempaquetado correctamente en el portátil y contiene el kernel esperado. No confundir el fallo de la herramienta host con una traza del teléfono.

Estado de LAB durante esta revisión

ADB disponible como usuario shell, sin privilegios root. LAB ya ejecuta combo4, kernel #16, sys.boot_completed=1. Pstore vacío. Propiedades de motivo de arranque: ro.boot.bootreason=reboot, sys.boot.reason=bootloader. No identifican el fallo previo. El tramo de logcat consultado no contiene una traza FORTIFY/CFI del intento fallido.

Intentos de leer módulos instalados en vendor devolvieron Permission denied. Por tanto, no se ha podido comparar su ABI/CRC con el kernel fallido. No se ha ejecutado adb root, cambiado Magisk, reiniciado ni flasheado LAB.

Prueba adicional de eficacia de wrappers

Se extrajo el bloque FORTIFY del string.h actual a un harness temporal, con sus wrappers y macros, tipos auxiliares y libc host. Clang r563880c, -O2 -flto -fuse-ld=lld. No se añadieron stubs overflow. El handler de fortify del harness termina con código 77 para observar el rechazo.

Directorio remoto: /tmp/axp-fortify-runtime-9t4hrer_.

13 casos dieron el resultado esperado:

• strlen/strnlen sobre una cadena válida, strcpy válido;
• memcpy, memmove, memset, memcmp y strncpy: tamaño 8 sobre buffers de 8 aceptado, tamaño dinámico 9 rechazado por fortify_panic.

Límites: ejecución host x86_64, no kernel ARM64; no prueba CFI del kernel, wrappers restantes, todos los call sites, módulos ni arranque. El caso memcmp usa el mismo buffer a ambos lados; no es una prueba exhaustiva de comparación. Estas pruebas muestran protección efectiva en los casos probados, no que el port completo sea correcto.

Lo que falta para atribuir el fallo

La corrección de límites resolvió el enlace, que era su alcance probado. No se ha identificado la instrucción que detiene el arranque. Encontrar llamadas a fortify_panic en el binario (incluso en funciones de inicio) es normal y no demuestra que se ejecuten durante el fallo.

Prioridad: preparar una captura de fallo utilizable antes del próximo ensayo. Comprobar en la referencia funcional el acceso y funcionamiento de pstore/ ramoops, incluido el mecanismo del dispositivo que procesa sus registros. Un arranque de diagnóstico puede instrumentar fortify_panic para registrar caller/backtrace conservando su comportamiento de fallo; también debe poder distinguir una caída CFI, un watchdog y un fallo de módulos. Esa instrumentación sin un canal persistente/serial verificado no garantiza obtener evidencia.

Conservar combo4 como referencia aceptada. No habilitar FORTIFY para ship, ni atribuir el fallo a un controlador concreto, ni reintroducir stubs/no-ops a partir del solo síntoma del logo. Revisar después compatibilidad de módulos y los call sites identificados por una traza real.

Plan de captura (siguiente documento): docs/009-fortify-diag-capture-plan.md.