AXP-Resurection/docs/009-fortify-clang-port.md

Status: attribution reference only (Clang FORTIFY). Not a runbook. Ship resume: 009-handoff-20261008.md.

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.