SergioandClaude Opus 5
46dba58616
SDD 25 tenía medido el sandbox por namespaces (T14, ~1 ms por proceso) pero no el grano fino que harkaq pone dentro, que cobra por SYSCALL. `bench_jaula.c` lo mide con control negativo en las dos mitades (si la jaula no quedó puesta, sale con 2). seccomp: el filtro de harkaq es una denylist lineal, así que toda syscall legítima recorre la cadena entera — y aun así es PLANO en su longitud (86,9 ns con 4 entradas, 88,3 con 250, sobre un piso de 75,0). Lo que lo hace plano es el bitmap de acción constante del kernel, y eso no se supone: un gemelo de la misma longitud con una carga de args[0] —que hace que el analizador se rinda— sí crece, 111,6 → 139,9 ns. La regla que sale de ahí es que un filtro es gratis mientras no mire un argumento. El bitmap se paga al instalar (1,5 µs por entrada) y se amortiza en 2 830 syscalls, o sea una invocación y media de gcc, una sola vez por fase de build. landlock: el precio es ESTAR enjaulado (+473 ns por open), no cuántas reglas hay — pasar de 1 regla a las 16 384 de una clausura fichero a fichero agrega +225 ns más. La política por-fichero de D1, que era la decisión discutible, resulta casi gratis. Y dos negativas medidas: `stat` no paga (Landlock no engancha getattr) y un open DENEGADO sale más barato que uno concedido, al revés de lo que se esperaba al medirlo. En total, la jaula le cuesta a un compilado 0,23–0,31%: una décima parte del presupuesto de <5% de SDD 16. De paso, dos cosas del filtro que salieron de mirarlo para medirlo: la denylist tiene un techo de ~252 entradas por el __u8 de los saltos de la BPF clásica, y el jf se calcula leyendo y modificando `k` en la misma expresión (UB en C11, benigno con gcc y clang, comprobado). Y §9.6 queda con el experimento de PTI bien planteado: no es «el laptop daría peor» (compara dos máquinas y mezcla cuatro variables) sino la misma máquina con pti=on y pti=off. momento no sirve ni forzándolo: este invitado no expone PCID, así que mediría el peor caso y no el de un TigerLake. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
Documentación de diseño de hammer
Estos documentos son la fuente de verdad del diseño. El código los implementa; cuando haya discrepancia, o se corrige el código o se actualiza el SDD con un commit que explique por qué.
Software Design Documents (SDD)
| # | Documento | Qué cubre |
|---|---|---|
| 00 | Visión y filosofía | Por qué existe, qué problema resuelve, la actitud de ingeniería |
| 01 | Arquitectura general | El modelo de dos mundos, componentes, flujo de datos |
| 02 | El laboratorio de build | Sandbox, zig cc, recetas, CAS, grafo de dependencias |
| 03 | Hidratación y store | Store content-addressed, hardlinks a FHS, patchelf, rollback |
| 04 | Overlay de experimentación | overlayfs en caliente, try/commit/discard |
| 05 | Diario de mutaciones | fanotify, log append-only, config-sin-ser-declarativa |
| 06 | Formato .swm |
Manifiesto de mutación compartible, esquema, firma |
| 07 | Bus de init y de agente | /run/init.control, /run/agent.sock, protocolo |
| 08 | Integración de la IA | El bucle agéntico, seguridad, intención → .swm |
| 09 | Modelo de confianza | Reproducibilidad, verificar-no-confiar, log de transparencia |
| 10 | Roadmap | Fases, MVP, primer entregable |
| 11 | Bootstrap from-scratch | Track posterior: Stage 0/1/2, auto-alojamiento, semilla pinned |
| 12 | arje como init real del Stage 1 |
Contrato de runtime: seed card, hammerd supervisado, CRASHED real |
| 16 | harkaq: la jaula de hammer | Landlock+seccomp sobre el bwrap actual; política = clausura; evidencia negativa de hermeticidad |
Runbooks (operativos)
| Runbook | Para qué |
|---|---|
| Validar Stage 1 booteando en QEMU | stage0→stage1→initramfs→QEMU; criterios de éxito y troubleshooting |
Architecture Decision Records (ADR)
Decisiones tomadas, con su contexto y consecuencias. Ver adr/.