From 2f0d5654e89e9b5f2031d4748e3042c9dbf32eca Mon Sep 17 00:00:00 2001 From: Sergio Date: Fri, 11 Sep 2026 21:31:02 +0000 Subject: [PATCH] =?UTF-8?q?ADR=200018:=20el=20arranque=20por=20vendor=20pa?= =?UTF-8?q?th,=20MEDIDO=20=E2=80=94=20el=20seguro=20se=20cobra?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Segunda enmienda, y cierra la primera del mismo día. El experimento: la MISMA imagen con la ruta fallback pisada con 4K de basura, dos corridas en OVMF que difieren SÓLO en la NVRAM. control (NVRAM limpia) → "No bootable option or device was found", cero líneas del initramfs prueba (con la entrada que escribió takana) → BdsDxe: starting Boot0004 "takana" from HD(1,GPT,DA80800E-…,0x800,0x30000)/\EFI\takana\takanax64.efi El firmware imprime el device path que decodificó: 0x800 = LBA 2048 y 0x30000 = 196608 sectores, exactamente los números que takana leyó del GPT. No es que "arrancó": arrancó POR la entrada que escribimos, con la fallback destruida. Es el escenario de Windows con el seguro cobrado. La idempotencia del §2 quedó probada en condiciones reales y no en un test: la segunda corrida dice "ya dice exactamente esto — no se reescribe" y "BootOrder ya empieza por Boot0004 — no se toca". La NVRAM tiene un número finito de escrituras y esto corre en cada arranque. El parser se validó además contra las CUATRO entradas reales del firmware (BootManagerMenuApp, EFI Firmware Setup, UEFI Misc Device, EFI Internal Shell): un vector que nadie escribió para que pasara. Y la dependencia efibootmgr se retira: no hizo falta. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01HHAKWoBqof9XvsYCvDicEj --- docs/adr/0018-soberania-del-arranque.md | 49 +++++++++++++++++++++---- 1 file changed, 41 insertions(+), 8 deletions(-) diff --git a/docs/adr/0018-soberania-del-arranque.md b/docs/adr/0018-soberania-del-arranque.md index b882e31a..cbb30c9b 100644 --- a/docs/adr/0018-soberania-del-arranque.md +++ b/docs/adr/0018-soberania-del-arranque.md @@ -1,6 +1,7 @@ # ADR 0018 — Soberanía del arranque: convivir con otro gestor sin depender de su buena fe -- **Estado:** PROPUESTO — **una decisión abierta** (§Secure Boot). El resto es implementable ya. +- **Estado:** PROPUESTO, con **§1 y §3 IMPLEMENTADOS y verificados en OVMF** (2026-09-11). + Queda **una decisión abierta** (§Secure Boot) y el §2/§4 por implementar. - **Fecha:** 2026-09-11 - **Frontera:** `scripts/install-image-efi.sh`, `scripts/install-image.sh`, `scripts/iso-image.sh`, `scripts/metal-usb-sdboot.sh`, `scripts/takana-live-install.sh`, el instalador TUI. @@ -102,11 +103,42 @@ Hace falta algo que no dependa de haber arrancado: > **del host**, no en un fichero `OVMF_VARS`; no hay `virt-firmware`; este OVMF no cae al UEFI Shell, > así que el truco del `startup.nsh` tampoco corre). > -> ⇒ **La copia en el vendor path es hoy un seguro que todavía no se puede cobrar solo.** Protege -> contra que *pisen el fichero*, pero sólo si además existe la entrada NVRAM del §1; sin ella el -> rescate es manual, desde el menú del firmware, en los firmwares que dejan navegar a un `.efi` -> arbitrario. **El §3 es condición necesaria y NO suficiente: sin el §1 la mitad del seguro falta.** -> Eso mueve la receta `efibootmgr` de «dependencia que este ADR crea» a **bloqueante del §3**. +> ⇒ **La copia en el vendor path es un seguro que todavía no se puede cobrar solo.** Protege contra +> que *pisen el fichero*, pero sólo si además existe la entrada NVRAM del §1. **El §3 es condición +> necesaria y NO suficiente: sin el §1 la mitad del seguro falta.** +> +> **↳ CERRADO el mismo día por la enmienda de abajo.** El bloqueo se levantó, y no con `efibootmgr`. + +> **ENMIENDA 2026-09-11 (2ª) — el §1 está implementado y el arranque por vendor path está MEDIDO.** +> +> La entrada NVRAM la escribe takana, no `efibootmgr`. Se intentó primero la vía ajena y el muro se +> midió: `efivar` 38 con musl/zig-cc choca con `secure_getenv` (no existe en musl), `sys/cdefs.h` +> (tampoco) y `-Wl,--add-needed` (lld lo rechaza) — tres muros sólo para compilar su generador de +> tablas, más `popt` arrastrado al sistema instalado. Lo que `efibootmgr` hace en el fondo es +> **escribir dos ficheros** con una estructura de la spec UEFI estable desde la 2.0. Está en +> `crates/takana-cli/src/efi_boot.rs` y se usa con `takana boot entry {list,add}`. +> +> **El experimento, que es lo que vale:** misma imagen de disco con la ruta fallback **pisada con +> 4 KiB de basura**, dos corridas en OVMF que difieren **sólo** en la NVRAM. +> +> | corrida | NVRAM | resultado | +> |---|---|---| +> | control | limpia | `No bootable option or device was found` — cero líneas del initramfs | +> | prueba | con la entrada que escribió takana | ✅ `BdsDxe: starting Boot0004 "takana" from HD(1,GPT,DA80800E-…,0x800,0x30000)/\EFI\takana\takanax64.efi` | +> +> El firmware imprime el device path que decodificó: `0x800` = LBA 2048 y `0x30000` = 196 608 +> sectores, **exactamente** los números que takana leyó del GPT. No es que «arrancó»: es que arrancó +> **por la entrada que escribimos, con la fallback destruida**. Eso es el escenario de Windows con +> el seguro cobrado. +> +> **Y la idempotencia del §2 quedó probada en condiciones reales**, no en un test: la segunda corrida +> vuelve a ejecutar el reconciliador y dice «la entrada Boot0004 ya dice exactamente esto — no se +> reescribe» y «BootOrder ya empieza por Boot0004 — no se toca». Importa más de lo que parece: la +> NVRAM tiene un número finito de escrituras y esto está pensado para correr en cada arranque. +> +> De paso, el parser se validó contra **las cuatro entradas reales del firmware** (`BootManagerMenuApp`, +> `EFI Firmware Setup`, `UEFI Misc Device`, `EFI Internal Shell`), que es un vector que nadie escribió +> para que pasara la prueba. ### 4. El instalador mira el terreno y lo dice en voz alta @@ -162,7 +194,8 @@ es neutral, es **mover el costo a la persona que instala**. ## Dependencias que este ADR crea -- Recetas nuevas: `efibootmgr` (o `efivar` y hablarle a la NVRAM desde el binario de takana). - Si se decide firmar: `sbsigntool`, y `shim`/`mokutil` en la variante shim. +- ~~Recetas nuevas: `efibootmgr` / `efivar`~~ — **resuelto sin dependencias nuevas**: la NVRAM la + escribe `takana boot entry add` (ver la 2ª enmienda). Si se decide firmar seguirá haciendo falta + `sbsigntool`, y `shim`/`mokutil` en la variante shim. - Los 5 scripts de arriba se parten en «medio removible» y «disco». - El instalador TUI gana el informe del terreno del §4.