`jt`/`jf` de la BPF clásica son __u8 y en la forma de poner_seccomp() el salto más largo mide n+3:
pasadas ~252 entradas el desplazamiento da la vuelta y el filtro deja de decir lo que dice el
fichero, sin error y sin aviso. Hoy son 25 y sobra sitio — el riesgo es que agregar syscalls a una
denylist es exactamente lo que uno hace sin pensarlo.
_Static_assert, o sea cero código generado: comprobado en las dos direcciones —baja el techo a 10 y
el compilador para; y la sección .text del binario es byte a byte la misma con y sin el assert—,
que es el requisito de este fichero (nada que re-hashee).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
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
Era el ultimo hueco medible de SDD 25 en esta maquina: H7 tenia el precio en cuatro partes
pero no el numero en bytes, que es como se pago H1.
Se construyo una copia derivada de linux-generic con UNA sola diferencia en el .config
(DEBUG_INFO_DWARF5 + DEBUG_INFO_BTF) y todo lo demas byte a byte igual:
bzImage sin BTF : 16 937 984 B
bzImage con BTF : 19 473 408 B (+2 535 424 B = +2,42 MiB = +14,97%)
seccion .BTF : 7 888 166 B sin comprimir, entran comprimidos 3,11x
Contra la unica vara comparable: H1 (MEMCG+PSI) costo +80 KiB / +0,49% del mismo bzImage
=> BTF cuesta 31 veces eso. No lo decide, pero lo saca de "un re-hasheo y ya".
Sobre linux-generic y no sobre linux, que es mas barato: BTF tiene depends on BPF_SYSCALL y
el .config sellado de linux lo trae APAGADO, asi que medir ahi habria mezclado dos precios.
TRES cosas que salieron construyendo y no leyendo:
1. Una QUINTA parte del precio que nadie habia nombrado: hace falta python3. BTF hace que
kbuild descienda a tools/bpf/resolve_btfids, que compila un libbpf vendorizado cuyo
Makefile genera bpf_helper_defs.h con un script de Python (Error 127).
2. El numero de Artix fallaba en la direccion CONTRARIA a la esperable. El doc decia que sus
6,4 MB "no dicen nada de uno monolitico y pelado"; el nuestro sale MAS GRANDE, 7,5 MiB.
Artix es modular y su .BTF cubre solo el core built-in; el nuestro es monolitico y los
tipos de i915+nouveau+radeon+iwlwifi entran todos.
3. Una trampa de kconfig que es CLAUDE.md §3 dentro de make: scripts/pahole-version.sh
imprime 0 si pahole no esta en el PATH, el depends on PAHOLE_VERSION >= 122 deja de
cumplirse, y olddefconfig BORRA la linea en silencio. El build sale OK y sella un kernel
SIN BTF diciendo que todo fue bien. Por eso la receta comprueba el .config PRODUCIDO y
sale 1 si no esta. Salio OK, lo que ademas paga la parte (3) del precio: el pahole
estatico de ayer se encuentra y se ejecuta DENTRO del sandbox.
El artefacto de medicion se borro a proposito: `hammer kernel contract --sealed` lo listaba
como SIN COMPROBAR (no declara [[target]], que es lo que exige H8), o sea un aviso permanente
en un fichero que el cron commitea cada 30 min. Un aviso fijo que no corresponde a ningun
problema es como se deja de leer un vigia. La receta derivada queda en la evidencia.
Nada del corpus se re-hasheo: la derivada vive fuera de recipes/ y el catalogo se le presta
por symlinks.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
El volumen del store estaba al 97% (8,8 G libres) con la granja escribiendo ahi, y el gordo
NO era el store: eran 79 G de `work/sources` — 106 arboles con el `target/` de cargo y los
`.o` dentro, porque el arbol de fuentes es tambien el directorio de compilacion. `pixi` pesaba
3,5 G y siete apps cosmic pasaban de 3 G cada una.
Nadie podaba eso: store-gc mira el store, la poda de CI mira la cache de CI, y este tercer
monton crecia sin dueno desde que el store se mudo al volumen.
Borrarlo no cuesta nada, y eso es lo que lo hace seguro: los dos caminos de fetch.rs
(fetch_git:73 y fetch_tarball:234) hacen `remove_dir_all` del arbol y lo re-extraen en CADA
build, sin una sola rama que reutilice. Un arbol viejo no acelera nada; la re-extraccion ocurre
igual. Lo unico que se pierde es el post-mortem del ultimo build, de ahi el suelo de 24 h.
El script toma `work/.farm-build.lock` porque el unico dano posible es borrar el arbol que un
bwrap esta compilando (ADR 0012 en su forma mas directa), y el mtime del directorio raiz no
distingue "viejo" de "build lento". Con espera acotada: si hay algo en vuelo salta el ciclo.
Suelo en HORAS y no en dias por la leccion de cache-ci-no-envejece: aquel cron podaba a +10
dias sobre datos de horas y liberaba cero. Los 106 arboles abarcaban 3 dias.
Sin umbral por espacio libre: podar solo cerca del borde convierte una poda barata y plana en
un pico justo cuando un build puede quedarse sin disco a mitad.
Probado en las cuatro ramas: dry-run vacio, dry-run con 15 candidatos, --aplicar sobre un arbol
sintetico (borra el viejo, deja los 15 recientes) y lock tomado (salta y sale 0).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
Tercer cable de la misma familia que el vigia de fuentes y el contrato del
kernel, y por la misma razon exacta: el gate existia desde julio, nadie lo
re-corria, y hoy el «MIENTEN: 0» con el que se habia cerrado el frente resulto
ser 4 — todas selladas DESPUES del cierre. Un frente que se cierra en cero y no
se vuelve a medir no se queda en cero.
Lo que costaba ese silencio, medido hoy: `bash` —el shell de los perfiles base,
cli y dos escritorios— NO ARRANCABA fuera del sandbox, y las cuatro apps GTK4
del corpus (hammer-edit incluida) segfalteaban en gtk_init. Todo sellado y en
verde.
PUERTA DIARIA por sello (`work/.static-audit.sello`, gitignoreado): el barrido
lee cada ejecutable de los ~750 sellados con file+readelf y tarda ~8 min de CPU
en 4 vCPU compartidos con el worker. Cada 30 min seria mas de un cuarto de core
para siempre vigilando algo que solo cambia al re-sellar. Con la puerta, 8 min
al dia. Forzar: `rm work/.static-audit.sello`.
El sello es LIMITADOR DE RITMO, no marca de exito ⇒ se toca en cuanto el barrido
termina, salga como salga. Si solo se tocara al acertar, un fallo que consuma
los 8 min se repetiria cada 30 y el cable pasaria de vigilancia a sangria.
No toma work/.farm-build.lock a proposito (solo LEE el store; retenerlo 8 min
pararia la granja) y va con `nice -n 19`: la prioridad la tiene construir.
El veredicto lleva FECHA DE MEDICION en la primera linea, y no es decoracion:
con el frente en verde el texto del audit es constante, `git diff --cached
--quiet` no veria cambio, no se commitearia nada, y en tres meses el fichero
seria indistinguible de uno rancio. Con la fecha, cada barrido deja huella en el
git log: se ve que el vigia sigue VIVO, no solo que el ultimo veredicto fue
bueno. Misma trampa que el build-state-wlr congelado 17 dias.
Comprobado en las dos direcciones, que es donde estos cables fallan callados:
la puerta abre sin sello / a las 25 h / a los 3 dias y cierra a las 0 h y 23 h;
y con un audit que sale !=0 sin imprimir nada, NO pisa el veredicto anterior,
toca el sello igual y no deja temporales. Ya corrio en el cron real: la cosecha
de 17:01Z commiteo docs/state/static-audit.txt y logueo «sello de hoy, no toca».
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
Los 8 ejecutables decian static y enlazaban musl dinamicamente. La huella que lo
delata sin mirar el build: `readelf --dyn-syms` daba 21475 entradas contra ~2700
de un binario dinamico normal — eso es --export-dynamic, no un enlace corriente.
NO venia del meson de gtk (ahi no aparece la palabra) sino de un .pc DE
DEPENDENCIA: `gmodule-2.0.pc` trae literalmente `Libs: -Wl,--export-dynamic`, y
`meson.build:426` pedia `dependency('gmodule-2.0')`. El wrapper de cc del lab
(`sandbox.rs:597`) tira el `-static` ante --export-dynamic ⇒ lo ponia el lab y
lo sacaba el lab, por un flag heredado de una dep.
No hace falta parchear el .pc de glib: upstream ya publica la misma libreria sin
el flag. `gmodule-no-export-2.0.pc` trae el `-lgmodule-2.0 -pthread` de verdad y
los otros dos solo hacen Requires sobre el añadiendo --export-dynamic. Es la
palanca prevista, no un apaño — de hecho `gio-2.0.pc` de la propia glib ya usa
la variante no-export.
REGLA GENERAL: cualquier receta que enlace gmodule hereda --export-dynamic y
pierde el -static SIN AVISO. Si link=static no pega y hay glib de por medio,
mirar los .pc de las deps antes que el build del proyecto.
Y entonces aparecio un bug que SOLO existe en estatico: los 8 morian con SIGSEGV
hasta en `--help`. Backtrace con gdb:
g_module_symbol (module=0x0, symbol_name="gtk_progress_get_type")
_gtk_module_has_mixed_deps (module_to_check=0x0) at gtk/gtkmain.c:474
do_pre_parse_initialization () at gtk/gtkmain.c:498
gtk_init_check () at gtk/gtkmain.c:635
`_gtk_module_has_mixed_deps(NULL)` hace `g_module_open(NULL,0)` y pasa el
resultado a `g_module_symbol` sin comprobarlo. En musl ESTATICO `dlopen(NULL)`
devuelve NULL siempre ⇒ deref de nulo en el offset 8, en el arranque. Con libc
dinamica el bug no se ve nunca. Cuarto parche de la receta: la comprobacion que
falta. Devolver FALSE es correcto ademas de seguro — en un estatico no hay
modulos cargables, asi que no puede haber simbolos de GTK 2/3 mezclados.
Control: 423 ficheros intactos, NEEDED=0 en los ocho, .dynsym de 21475 a 0, los
ocho arrancan, gtk4-path-tool hace trabajo real, y `builder-tool validate`
devuelve EXACTAMENTE el mismo «Could not initialize windowing system» que daba
el binario dinamico anterior.
Cae en cascada el re-hash de 7 dependientes; se reconstruyen a continuacion.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
