Files
AXP-Resurection/docs/009-fortify-clang-port.md
T
sunfish-admin deaaf42caa 009: Magisk ship pack through US-S5-1 + US-S4 OpenSSH/Jelly/Gallery2.
Release-keys/AVB, CVE clean+hi batches, Yama/slabrand, Pro branding,
bundled apps, and AXP-class product surface docs/scripts.
2026-10-05 10:42:00 +02:00

99 lines
5.1 KiB
Markdown

# FORTIFY + Clang en msm-4.14 (plan de port)
Documento de preparación. No es un parche listo. Relacionado:
`docs/009-fortify-boot-audit-20260926.md` (diagnóstico del fallo LAB).
## Hechos ya cerrados
| Hecho | Evidencia |
|-------|-----------|
| Packaging ksync OK | Ramdisk/DTB idénticos a slab; patch `2026-09` |
| FORTIFY one-CONFIG tumba arranque | LAB → reinicios → fastboot; pstore vacío |
| DMESG / SLAB / INIT_ON_ALLOC / INIT_ON_FREE solos OK | Bisect ksync 2026-09-26 |
| `depends on !CC_IS_CLANG` es inútil aquí | `CC_IS_CLANG` **no existe** en msm-4.14; el build usa Clang 21 + LTO/CFI |
| Stubs `__read_overflow*` + `BUG()` | Anti-patrón: enlazan pero dejan llamadas reales (p.ej. `q6_dlkm` → `__read_overflow2`). **No reutilizar** |
| AXP `fortify/4.14/0004.patch` | Solo intra-object (`FORTIFY_SOURCE_STRICT_STRING` / Micay). **No** aporta soporte Clang |
## Qué hace falta (upstream, no inventado)
Serie Kees Cook *fortify: Add Clang support* (v7, 2022-02), mergeada en kernels
modernos. Idea central:
1. Atributos Clang: `__pass_object_size`, `__overloadable`, `__diagnose_as`
(en `compiler_attributes.h`).
2. Wrappers FORTIFY adaptados para que `__builtin_object_size(p, 1)` funcione
desde inlines (en kernels nuevos: `include/linux/fortify-string.h`).
3. Kconfig: `depends on !CC_IS_CLANG || CLANG_VERSION >= 120001` (y exclusiones
arch específicas). Clang 21 cumple la versión; falta el código.
Referencias:
- Cover: <https://lists.openwall.net/linux-hardening/2022/02/08/7>
- Commit ilustrativo: `281d0c962752` (*fortify: Add Clang support*)
- Antecedente del disable: `a52f8a59aef4` / bugs LLVM 41459, 50322
En **4.14** el FORTIFY vive todavía dentro de `include/linux/string.h` (no hay
`fortify-string.h`). El backport no es un cherry-pick limpio: hay que adaptar
los wrappers al layout 4.14 o traer la separación de headers con cuidado.
## Detección de compilador (paso previo pequeño)
Sin `CC_IS_CLANG` / `CLANG_VERSION` en Kconfig, cualquier `depends on !CC_IS_CLANG`
es no-op. Antes o junto al port de wrappers:
1. Backport mínimo de los símbolos Kconfig que usan árboles Android/comunes
modernos (`CC_IS_CLANG`, `CLANG_VERSION`) **o** equivalencia documentada
vía `scripts/Kconfig.include` / Makefile del árbol.
2. Con eso solo + `depends on !CC_IS_CLANG`: FORTIFY queda **apagado** con
Clang — correcto, pero no da hardening. Sirve como red de seguridad para
no volver a activarlo “por accidente”.
## Camino de implementación propuesto (orden)
1. **Quitar stubs** de `009-bisect-ksync-one.sh` (o dejarlos detrás de un
flag explícito `ALLOW_FORTIFY_BUG_STUBS=1` no usado por defecto). Un
FORTIFY que no enlace sin stubs = señal de que el port está incompleto.
2. **Introducir detección Clang** en Kconfig (paso pequeño, testeable).
3. **Port wrappers Clang** al `string.h` 4.14 (o split a `fortify-string.h`
si el diff queda más limpio), tomando la serie Kees como fuente, no stubs.
4. **Build ksync** solo `CONFIG_FORTIFY_SOURCE=y` (sin STRICT_STRING al
principio). Criterio de éxito: modpost **sin** undefined
`__read_overflow*` y sin exportar cuerpos `BUG()`.
5. Si aparecen llamadas residuales en audio/WLAN: tratar cada una como bug
de tamaño/objeto o fallo del wrapper — no enmascarar.
6. Flash LAB (mismo método ksync / GOODMAKE). Solo entonces valorar
`FORTIFY_SOURCE_STRICT_STRING` (AXP 0004) encima.
7. Reintroducir FORTIFY en el combo defconfig OK (DMESG+SLAB+INIT_ON_*).
Fuera de alcance de este port: desactivar LTO/CFI globales “para que compile”
(introduce otra variable y pierde protecciones ya validadas).
## Qué no es “clonar AXP” aquí
AXP aporta el parche Graphene de **strict string** sobre un FORTIFY que ya
debe ser válido con el toolchain del producto. En LOS23/sunfish el toolchain
es Clang+LTO; el vacío es el **soporte Clang de FORTIFY**, no el 0004.
Hasta tener (3)+(4), no marcar FR-017 FORTIFY como listo.
Nota (búsqueda host): el `0008-…-fortify/5.15/0006.patch` AXP (*rewrite
fortify source for 5.15 gki*) también es strict-string sobre
`fortify-string.h` ya existente — no sustituye la serie Kees de Clang.
## Estado
- **LAB combo4 OK** (2026-09-26): `#16`, DMESG+SLAB+INIT_ON_ALLOC+INIT_ON_FREE, sin FORTIFY.
- Stubs BUG gated off en ksync (`ALLOW_FORTIFY_BUG_STUBS`).
- Port en curso: `vendor/.../fortify-clang/apply_fortify_clang.py`.
- **fortify-pos0 FAIL 2026-09-26T21:54Z:** modpost
`__read_overflow*` undefined en `q6_dlkm.lto.ko` / `wlan.lto.ko`.
**vmlinux/Image.lz4 sí generaron** (sin esos U en el núcleo). El port POS0
no basta aún para módulos LTO; no reintroducir stubs.
Siguiente: localizar call sites (p.ej. rtac) o `__NO_FORTIFY` puntual /
más del port Kees — no ACCEPT hasta harness + link limpio.
- **Ensayo 2026-09-26T22:06Z:** POS0 + bounds (`rtac`/`lim_process_fils`) en
job `009-bisect-ksync-fortify-bounds`. Log:
`detach-009-bisect-ksync-fortify-bounds-20260926T220634Z.log`.
**Build OK / LAB FAIL:** logo Google → reboot. Reflasheo a combo4.
Bounds resolvieron el link; no bastan para arrancar. FORTIFY sigue
aparcado para ship hasta traza o port más completo + harness.