tawasuyu

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

TOML 1572Shell 203Rust 109Markdown 993728 Definiciones

plan-botar-busybox: el frente C medido — y el obstaculo no es tecnico

Los cuatro consumidores de busybox en la raiz de confianza estan cubiertos:
  /bin/sh de scripts y cards  → simi, DIVERGE=0 en 1339 casos
  el login de consola         → simi, desde que tiene editor de linea
  setuidgid de las 5 cards    → recipes/setuidgid.toml, sellado y declarado
  halt/poweroff/reboot        → los shims de arje-botones.sh
  switch_root                 → util-linux, /sbin/switch_root (verificado)

Y la superficie del stage1 son TRES cosas, no un userland: leyendo
REBUILD_DRIVER, antes de `export PATH=/toolchain/...` solo se usan /bin/sh,
/bin/mkdir y /bin/cp. Despues, todo sale de /toolchain — lo dice el propio
driver: «usa el busybox estatico ANTES de tocar el PATH».

Dos formas de hacer el swap, con su precio medido:
  A · busybox → simi + coreutils(GNU, estatico): 972 K → ~6 MB
  B · pre-colocar el shim del loader al ARMAR el rootfs ⇒ el driver no necesita
      ninguna orden externa y el swap es busybox → simi a secas: 972 K → 508 K,
      o sea MENOS. Viable: seed_toolchain_dir() resuelve el toolchain desde el
      store, asi que esta disponible al armar.
⇒ B es mas chica y mas limpia.

⚠ Y NO se hizo porque no es verificable hoy en NINGUNA de las dos cajas. Tocar
STAGE1_COMPONENTS cambia el of_tree, y el unico control es reconstruir el
stage1 y comparar contra el ancla de selfhost-verify.sh. Eso pide la semilla del
toolchain, y medido: hub y worker tienen SOLO seed-zig. El otro control
(product-boot-test.sh) pide QEMU: el hub no tiene ni /dev/kvm ni qemu; el worker
tiene qemu sin KVM (sirve por TCG) pero eso valida el PRODUCTO, no el stage1.

Cambiar la raiz de confianza del arranque sin poder reconstruirla ni arrancarla
es la clase de cambio que este repo no hace. Lo que falta no es decidir ni
escribir: es poder MEDIR. Quedan anotados los dos pasos que lo destraban.

b975aaa3541dd2cbea44e5d195a102cb2c60044e · por Sergio · (hace 10 h) · padre 56c33c212 · ver el árbol en este commit

Delta semántico

Ninguna definición cambió: el cambio es de texto, documentación o datos.

1 archivos · +67 −0

diff --git a/docs/plan-botar-busybox.md b/docs/plan-botar-busybox.md
index 9b3999de..d8e1ea66 100644
--- a/docs/plan-botar-busybox.md
+++ b/docs/plan-botar-busybox.md
@@ -257,6 +257,73 @@ el paso siguiente y todo lo demás es independiente de él.
 que los applets ya retirados siguen vivos ahí hasta que se rehaga la imagen — medir «qué usa el
 producto» contra esa caja da un resultado más gordo que el real.
 
+## FRENTE C — la superficie exacta, medida 2026-10-22 (y por qué se para acá)
+
+El plan decía que el frente C es «sustituir busybox en `STAGE1_COMPONENTS` y `ATTEST_PATHS`» y lo
+dejaba para el final. Medido, es MUCHO más chico de lo que ese nombre sugiere — y el obstáculo no
+es técnico.
+
+### Dónde está busybox en la raíz de confianza, exactamente
+
+| sitio | para qué |
+|---|---|
+| `ATTEST_PATHS` → `bin/busybox` | su propio comentario lo dice: *«shell (`/bin/sh`) + exec del card de sshd»* |
+| card de sshd | `sh -c "netup; ssh-keygen -A; exec sshd -D -e"` — un `sh -c` trivial |
+| card de getty | `agetty -n -l /bin/sh` — el login de consola |
+| `STAGE1_COMPONENTS` | el userland mínimo del driver de reconstrucción |
+
+Y en el stage1 la superficie son **TRES cosas**, no un userland: leyendo `REBUILD_DRIVER`, antes de
+`export PATH=/toolchain/...` sólo se usan `/bin/sh` (el shebang), `/bin/mkdir -p /lib` y
+`/bin/cp -f` del shim del loader musl. **Después de esa línea todo sale de `/toolchain`** — el
+propio driver lo dice: *«Usa el busybox estático (rutas absolutas) ANTES de tocar el PATH»*.
+
+### Los cuatro consumidores, y los cuatro están cubiertos
+
+- `/bin/sh` de scripts y cards ⇒ **`simi`**, DIVERGE=0 en 1339 casos (1329 fases reales).
+- el login de consola ⇒ **`simi`** también, desde que tiene editor de línea, historial y Tab.
+- `setuidgid` de las cinco cards ⇒ **`recipes/setuidgid.toml`**, sellado y declarado.
+- `halt`/`poweroff`/`reboot` ⇒ los shims de `arje-botones.sh`, y el de poweroff ya baja servicios.
+- `switch_root` ⇒ **`util-linux`** lo trae en `/sbin/switch_root` (verificado en el artefacto).
+
+### Las dos formas de hacer el swap del stage1, con su precio
+
+**A · busybox → simi + coreutils(GNU, estático).** Mecánico. El `coreutils` del store es estático
+(`NEEDED=0`, multicall de 1,8 MB con `mkdir`/`cp` como enlaces). Precio: esa parte de la raíz de
+confianza pasa de **972 K a ~6 MB**.
+
+**B · pre-colocar el shim del loader al ARMAR el rootfs.** El driver copia
+`/toolchain/lib/ld-musl-x86_64.so.1` a `/lib/` en tiempo de arranque; si `assemble_and_seal` lo
+deja puesto, el driver **no necesita ninguna orden externa** antes del PATH y el swap es
+`busybox → simi` a secas: **972 K → 508 K, o sea MENOS**. Es viable: `seed_toolchain_dir()`
+resuelve el toolchain desde el store, así que está disponible al armar. Y de paso el loader entra
+en el hash del rootfs, que es más reproducible que copiarlo al vuelo.
+
+⇒ **B es más chico y más limpio.** Es la que hay que hacer.
+
+### ⚠ Por qué NO se hizo: no es verificable hoy en ninguna de las dos cajas
+
+Tocar `STAGE1_COMPONENTS` cambia el `of_tree` del stage1, y el único control que existe es
+reconstruirlo y comparar contra el ancla de `scripts/selfhost-verify.sh`
+(`EXPECT_REF=b3:d152f060…`). Para eso hace falta `takana bootstrap stage1`, y eso pide la **semilla
+del toolchain**. Medido:
+
+    hub    : /store/*seed-*            ⇒ sólo `seed-zig`
+    worker : /opt/takana/store/*seed-* ⇒ sólo `seed-zig`
+
+**Ninguna de las dos tiene la semilla del toolchain.** Y el otro control, `product-boot-test.sh`,
+necesita QEMU: el hub no tiene ni `/dev/kvm` ni qemu; el worker tiene `qemu-system-x86_64` sin KVM,
+o sea que puede correr por emulación TCG (`KVM=0`), pero eso valida el PRODUCTO, no el stage1.
+
+⇒ Cambiar la raíz de confianza del arranque sin poder reconstruirla ni arrancarla es exactamente la
+clase de cambio que este repo no hace. **Lo que falta no es decidir ni escribir: es poder medir.**
+
+Para destrabarlo hacen falta dos cosas, en este orden:
+1. **la semilla del toolchain sellada** en alguna de las dos cajas (`takana bootstrap stage0`), que
+   es lo que habilita reconstruir el stage1 y comparar el `of_tree`;
+2. el `product-boot-test.sh` en el worker con `KVM=0` para el lado del producto.
+
+Con esas dos, el cambio B es media hora de código y una tarde de emulación.
+
 ## La métrica, y el guardián que falta
 
 `docs/state/busybox-applets.tsv` convierte esto en un número que baja: **401 → 272 → … → 0**.