# 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.