sunfish-admin
deaaf42caa
Release-keys/AVB, CVE clean+hi batches, Yama/slabrand, Pro branding, bundled apps, and AXP-class product surface docs/scripts.
88 lines
4.4 KiB
Markdown
88 lines
4.4 KiB
Markdown
# 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`.
|