1# ADR 0017 — Ciclo de vida del kernel: cambiarlo sin pagar el reboot
2
3- **Estado:** PROPUESTO, con **§1, §2 y §4 IMPLEMENTADOS y verificados en OVMF** (2026-09-12).
4  Siguen **las dos decisiones abiertas** (ver §Lo que no decide este ADR); ninguna bloquea lo hecho.
5- **Fecha:** 2026-09-11
6- **Frontera:** `recipes/linux-*.toml`, `crates/takana-cli/src/kernel_cmd.rs`, el GC del store.
7- **Hermano:** [ADR 0018](0018-soberania-del-arranque.md) — arrancar el kernel nuevo es otro
8  problema y tiene su propio fichero. **Relacionado:** [SDD 22](../22-configurador-kernel.md)
9  (el armador), [SDD 25](../25-tasas-del-kernel.md).
10
11## Contexto
12
13El problema de actualizar kernels en una distro normal no es técnico: es que **el kernel es un
14nombre mutable**. `/boot/vmlinuz-6.16.12` es un fichero que se sobreescribe, y conservar los N
15anteriores es una convención que se rompe sola cuando `/boot` se llena. De ahí sale todo lo demás —
16el rollback deja de ser una operación y pasa a ser un procedimiento con pasos que hay que recordar
17bajo presión.
18
19En takana el kernel es un artefacto de contenido: el viejo y el nuevo coexisten sin disputarse un
20nombre. **La mitad de este problema está resuelta por construcción y sin haberlo buscado.** Esto
21importa porque cambia dónde conviene invertir:
22
23> Una distro no se hace fuerte logrando que la actualización no falle.
24> Se hace fuerte logrando que **fallar no cueste nada**.
25
26## Lo medido (2026-09-11)
27
28Sobre los `.config` **sellados en `./store`**, no sobre las recetas — el `.config` producido es la
29identidad del artefacto (SDD 22 §1) y es lo único que dice qué kernel hay de verdad.
30
31| kernel (store) | `KEXEC` | `KEXEC_FILE` | `LIVEPATCH` | `MODULES` | `EFI_STUB` | `CMDLINE_BOOL` |
32|---|---|---|---|---|---|---|
33| `linux` `d2a03c29` | ✅ | — | — | **✅** | ✅ | — |
34| `linux-generic` `23f1cc43` | ✅ | — | — | — | ✅ | ✅ |
35| `linux-metal` `2ed8f54a` | ✅ | — | — | — | ✅ | ✅ |
36| `linux-metal-dual` `714f46d6` | ✅ | — | — | — | ✅ | ✅ |
37| `linux-gioser` `8ffd5710`, `b026fe14` | ✅ | — | — | — | ✅ | ✅ |
38
39Cuatro consecuencias, y ninguna es opinión:
40
411. **`CONFIG_KEXEC=y` en los 6.** La primitiva para cambiar de kernel sin pasar por el firmware
42   **ya está pagada en todo el corpus**, gratis, heredada del `defconfig` de x86. No hay que
43   re-hashear nada para empezar a usarla.
442. **`CONFIG_LIVEPATCH` en ninguno.** Lo que sí aparece es `CONFIG_HAVE_LIVEPATCH=y`, que es
45   *capacidad de la arquitectura*, no el feature — confundirlos es exactamente el modo de error que
46   este repo ya tiene nombrado: la etiqueta no es el hecho.
473. **`CONFIG_MODULES` sólo en `linux`.** Los cinco kernels que arrancan máquinas son monolíticos
48   (`recipes/linux-metal.toml:108` lo apaga a propósito). **Un livepatch *es* un `.ko`** ⇒ en esos
49   cinco kernels el livepatch está cerrado por construcción, no por falta de trabajo.
504. **`CONFIG_KEXEC_FILE` en ninguno.** Sólo existe el syscall viejo `kexec_load`. Con *lockdown*
51   activo (lo que trae Secure Boot) el kernel **rechaza `kexec_load`** y sólo acepta
52   `kexec_file_load` con imagen firmada. ⇒ **kexec y Secure Boot no coexisten hoy**, y eso ata este
53   ADR con el 0018 §Secure Boot.
54
55Y el estado de la herramienta: `takana kernel` tiene hoy nueve subcomandos —`closure`, `probe`,
56`bundles`, `plan`, `diff-back`, `gate`, `hw`, `contract`, `stats`— y **ninguno escribe nada**. SDD 22
57construyó deliberadamente un armador que sólo analiza. Los verbos que propone este ADR serían los
58primeros del namespace que actúan sobre la máquina, y esa frontera merece cruzarse a propósito.
59
60No existen en el catálogo `kexec-tools`, `efibootmgr`, `sbsigntool`, `shim`, `mokutil` ni `efivar`.
61
62## Decisión
63
64### 1. Tres verbos, nombrados por lo que cuestan
65
66Casi toda la industria vende «live kernel update» y entrega una de tres cosas distintas. Takana
67nombra las tres por separado y **no llama a ninguna lo que no es**:
68
69| verbo | qué hace | downtime | alcance | perfil |
70|---|---|---|---|---|
71| `takana kernel stage <hash>` | deja el kernel listo; entra en el próximo reboot natural | **cero** | total | escritorio |
72| `takana kernel kexec <hash>` | reboot **suave**: salta firmware y gestor de arranque | ~2 s, **mata el userspace** | total | servidor |
73| *(livepatch)* | parchea funciones del kernel vivo | cero real | **una función** | CVE en producción |
74
75`kexec` **no es «sin rebootear»** y la ayuda del comando tiene que decirlo con esas palabras. Lo que
76ahorra son los 20–30 s de POST/UEFI, que en un servidor remoto es la mitad del downtime y en un
77portátil no es nada. Ser la distro que **no confunde las tres** ya es una posición: la confusión es
78la norma del mercado.
79
80> **ENMIENDA 2026-09-12 (2ª) — `kernel kexec` implementado, y por `kexec_file_load`.**
81>
82> La diferencia entre los dos syscalls es de **orden de magnitud**, y decide el frente entero:
83>
84> - `kexec_load` (el que traen los seis kernels sellados) recibe los **segmentos ya armados** y el
85>   *purgatory* —el código que corre entre los dos kernels—. Usarlo obliga a reimplementar
86>   kexec-tools, o a empaquetarlo.
87> - `kexec_file_load` recibe los **descriptores** del kernel y del initrd y hace el trabajo adentro.
88>   **~50 líneas**, sin dependencias ajenas.
89>
90> El syscall va con `asm!` en vez de agregar la crate `libc` al workspace: es **un** syscall, su
91> número y su ABI son contrato estable de Linux, y la alternativa era arrastrar una dependencia a un
92> workspace que comparten dos frentes. El cmdline viaja **con su NUL** — el kernel cuenta
93> `cmdline_len` incluyendo el terminador, y es el error clásico de esta llamada.
94>
95> **Y esto responde media decisión abierta n.º 2.** `recipes/linux-metal-kexec.toml` es una variante
96> cuya única diferencia es `CONFIG_KEXEC_FILE=y`. Variante y no flag en la canónica porque el
97> `.config` **es** la identidad del artefacto (SDD 22 §1) y esa decisión es del usuario; comprobado
98> que la canónica **no se movió** (`b3:2ed8f54a…`, el que ya está sellado). Con ese flag, kexec y
99> Secure Boot **pueden** coexistir: lockdown prohíbe `kexec_load` y acepta `kexec_file_load` con
100> imagen firmada. Lo que queda por decidir es si se firma, no si es posible.
101>
102> **Un diagnóstico que corregí a los dos minutos de escribirlo, porque mandaba al lugar OPUESTO.**
103> El primer `match` de errno decía «falta `CONFIG_KEXEC_FILE`» para **EPERM**. Medido en este mismo
104> hub: el kernel de Artix trae `CONFIG_KEXEC_FILE=y` y aun así devolvió EPERM — **por no ser root**.
105> EPERM es falta de `CAP_SYS_BOOT` (o lockdown, si ya sos root); **ENOSYS** es el flag que falta.
106> Confundirlos manda a recompilar un kernel que estaba perfecto. Es la tercera vez en dos días que
107> el error caro no es el mecanismo sino **el mensaje que explica el mecanismo**.
108
109### 2. A/B con vuelta atrás automática — esto es lo que vale
110
111`kexec` solo no hace fuerte a nadie: hace *rápido*. Lo que hace fuerte es que **si el kernel nuevo
112no llega a “sistema sano” en T segundos, la máquina vuelve sola al anterior.**
113
114- systemd-boot aproxima esto con contadores en el *nombre del fichero* (`+3-0`). Takana puede
115  hacerlo mejor porque el estado al que volver es **un hash**, no un fichero que puede no estar.
116- Qué es «sano» lo declara el perfil, no el kernel: para `perfil.servidor` es que arje-zero levantó
117  sus servicios supervisados; para un escritorio, que el compositor pintó.
118- **Sin esto, actualizar el kernel de una máquina remota da miedo, y con razón.** Es la única
119  entrada de esta lista que yo pondría primero.
120
121> **ENMIENDA 2026-09-12 — el §2 implementado, y la vuelta atrás la hace el FIRMWARE.**
122>
123> `takana kernel {stage, boot-status, confirm, rollback}`. El hallazgo que lo vuelve barato: hay **dos
124> modos de fallo y sólo uno necesita código nuestro**.
125>
126> 1. **El candidato no arranca** (pánico temprano, EFI-stub que el firmware rechaza). Lo cubre
127>    **`BootNext`**, y sale gratis: es una variable **de un solo uso** que el firmware **consume** al
128>    leerla. Si el kernel muere, el siguiente arranque ya no la encuentra, cae en `BootOrder` y vuelve
129>    al estable **sin que corra una sola línea nuestra**. No hay contador que mantener ni estado que
130>    se pueda corromper — el mecanismo *es* el firmware, y por eso no se puede romper.
131> 2. **Arranca pero el sistema no queda sano.** Eso el firmware no lo puede saber ⇒ confirmación
132>    explícita, y cada arranque sin confirmar gasta un intento.
133>
134> **Verificado con dos kernels REALES del store, cuatro arranques en OVMF:**
135>
136> | # | qué pasó | evidencia |
137> |---|---|---|
138> | 1 | estable 6.16.12, sin candidato → `stage` del 7.1.2 | `copiado (17142784 bytes)` · `BootNext = Boot0004` |
139> | 2 | **arranca el candidato** | `starting Boot0004 "takana (candidato)"` · `AB: kernel corriendo = 7.1.2` · `⏳ EN PRUEBA` → `confirm` → `✓ promovido` |
140> | 3 | arranque normal: el estable **cambió** | `AB: kernel corriendo = 7.1.2` · `sin candidato` |
141> | 4 | **`stage` de un candidato ROTO** (4 KiB de basura) y reinicio | `starting Boot0002` —la ruta normal— · `AB: kernel corriendo = 7.1.2` · `✗ el candidato Boot0004 NO arrancó: esta sesión vino del estable` |
142>
143> La fila 4 es la que justifica todo: **la máquina sobrevivió a que le instalaran un kernel que no
144> arranca, sin que nadie interviniera, y además sabe que pasó.**
145>
146> Tres decisiones que la prueba obligó a tomar:
147> - **El candidato va a una ranura propia de la ESP**, nunca encima del estable: un fallo a media
148>   copia dejaría sin kernel al que volver. La copia es `tmp` + `rename`.
149> - **`stage` repone el `BootOrder`** después de crear la entrada. `reconcile` deja al candidato
150>   primero —correcto para el ADR 0018, incorrecto acá—: un candidato tiene que arrancar **una vez**,
151>   no volverse el default. Para eso está `BootNext`.
152> - **El estado A/B tiene que persistir.** El primer banco de pruebas lo tenía en un tmpfs y `stage` +
153>   reinicio lo perdía. **Falló seguro** —dijo «sin candidato» y no promovió nada— pero dejaba la
154>   entrada NVRAM huérfana sin que nadie lo supiera. Ahora `boot-status` se lo pregunta al firmware,
155>   que es la fuente de verdad, y lo dice.
156>
157> Y un bug que cazó un **test**, no una revisión: `en_esp` normalizaba los backslashes *después* de
158> quitar la barra inicial, así que una ruta en formato EFI salía como `/EFI/…` —absoluta— y
159> `Path::join` con una ruta absoluta **descarta la base**: habría escrito en el `/EFI` de la raíz del
160> sistema en vez de dentro de la ESP.
161
162### 3. El kernel corriendo se identifica por **hash**, no por `uname -r`
163
164`uname -r` dice `6.16.12` y no dice qué `.config`, qué parches ni qué toolchain. Eso es el bug
165clásico de los livepatches y los módulos fuera de árbol: se construyen contra el kernel equivocado y
166el síntoma aparece meses después. Con el hash del artefacto viajando en el kernel vivo —el cmdline
167embebido ya lo permite en 5 de los 6— la pregunta «¿esto corresponde a este kernel?» pasa de
168heurística a **comparación exacta**.
169
170Es un cierre de invariante, no una comodidad.
171
172### 4. El kernel EN EJECUCIÓN es raíz del GC
173
174No el de la entrada de arranque: **el que está corriendo**. Si el GC poda el artefacto del kernel
175vivo, se pierden el rollback y la capacidad de diagnosticar, **y se pierden en silencio** — el
176sistema sigue andando perfecto hasta el día que lo necesitás. Es el mismo patrón que ya costó caro
177en el CAS: lo que no es alcanzable desde una raíz desaparece sin avisar.
178
179⇒ `scripts/store-gc.sh` y cualquier GC nuevo leen el hash del kernel vivo y lo tratan como raíz.
180Guardián con **rotura a propósito y control que tiene que pasar**, no sólo con el caso feliz.
181
182> **ENMIENDA 2026-09-11 — el §4 está implementado en `scripts/store-gc.sh` y probado en los tres
183> sentidos.** El GC suma ahora una raíz: el artefacto de kernel cuyo `boot/config-*` coincide byte a
184> byte con el `.config` del kernel vivo (`/proc/config.gz`, o `/boot/config-$(uname -r)`).
185>
186> | caso | esperado | resultado |
187> |---|---|---|
188> | store de juguete con el kernel **vivo** marcado «superado» | se rescata | ✅ movido a vigentes, y lo **dice**: «1 estaban marcados para BORRAR y se rescataron» |
189> | **control:** un kernel con `.config` distinto, también marcado | **sigue condenado** | ✅ no protege de más |
190> | store real, en el hub (kernel ajeno de Artix) | no protege nada, y lo explica | ✅ «NINGUN artefacto del store lo tiene» |
191>
192> El control del medio es el que importa: sin él, una función que devolviera «protegido» siempre
193> pasaría la primera prueba y volvería inútil al GC sin que nadie lo notara.
194>
195> Identifica por **contenido del `.config`**, no por hash de artefacto: dos artefactos con el mismo
196> `.config` y distinta toolchain se protegen los dos. Es el lado correcto para un GC, y se vuelve
197> exacto el día que el §3 ponga el hash en el kernel vivo.
198
199### 5. Si alguna vez hace falta livepatch, es una **variante**, no un flag
200
201La salida correcta **no** es encender `MODULES` en el kernel general —eso revierte una decisión de
202reproducibilidad y superficie de ataque para todo el mundo—. Es una variante
203`linux-servidor-livepatch` con su propio hash, para el perfil que la pida. En takana las variantes
204son baratas; lo caro es descubrir dentro de dos años que la puerta se cerró sin que nadie supiera
205que la estaba cerrando.
206
207### 6. El límite que este ADR no cruza, dicho en voz alta
208
209Para «actualizar **sin interrumpir el trabajo**» la respuesta no está en el kernel: es CRIU o drenar
210la carga a otra máquina. **Ninguna distro resuelve eso**, y prometerlo es donde empiezan las
211mentiras de la categoría. `stage` + `kexec` + rollback automático es el techo honesto.
212
213## Lo que no decide este ADR
214
2151. **¿El perfil servidor quiere livepatch?** ⛔ **ABIERTA.**
216   Si **sí**: hay que prever la variante con `MODULES` ahora y aceptar su costo (superficie de
217   módulos cargables, `vermagic`, firma de módulos si además hay Secure Boot).
218   Si **no**: hay que escribirlo como decisión explícita, para que dentro de un año nadie lo
219   «arregle» encendiendo módulos en el kernel general creyendo que fue un olvido.
220
2212. **¿`kexec` es compatible con el destino de Secure Boot?** ✅ **RESPONDIDA (2026-09-12): sí, con
222   `KEXEC_FILE`.** Ya no es una incógnita técnica sino un costo conocido: existe
223   `recipes/linux-metal-kexec.toml` con el flag, y bajo lockdown ese es justamente el syscall que el
224   kernel acepta. Lo que queda abierto es **si el perfil que use kexec adopta esa variante** (un
225   artefacto de kernel más) o si se enciende el flag en la canónica (re-hashea el kernel de todas
226   las imágenes). Eso sí sigue siendo decisión del usuario, pero es una decisión de *coste*, no de
227   viabilidad.
228
229## Riesgos conocidos
230
231- **El cmdline está embebido** (`CONFIG_CMDLINE_BOOL`, `linux-metal.toml:150`) porque el arranque
232  normal es por EFI-STUB. `kexec` **no usa el stub**: carga por el protocolo de boot de Linux, así
233  que initrd y cmdline hay que pasárselos explícitos. El traspaso de la EFI memmap por `setup_data`
234  con `efi=novamap` puesto **es el punto a probar en QEMU antes de tocar metal** — no está
235  verificado y no debe darse por bueno.
236- **El monolítico es una ventaja acá**: sin módulos no hay `vermagic` ni `/lib/modules` que se
237  desincronicen. El modo de fallo clásico de «actualicé el kernel y no rebooteé» —enchufás un USB y
238  no pasa nada porque el módulo ya no está en disco— **no existe en takana**. Vale anotarlo del lado
239  del haber cuando se discuta el punto 1.