================================================================================ Rootfs + first-fs-loaded execve model for the wasm32 port ================================================================================ This document is the spec-first opener for K6. K6's deliverable is the **kernel-side filesystem and exec surface**: a real initramfs unpacked into a real rootfs, a kernel that opens ``/init`` via real ``do_execve`` machinery, and a ``binfmt_wasm.load_wasm_binary`` that reads the WASM bytes from the file (not from an embedded ``.rodata`` blob). The payload binary K6 boots is **still K5's libwacky-built ``hello-k5.wasm``**, repositioned from embedded-in-vmlinux to lying on the initramfs as ``/init``. The "first real userland" milestone — a binary linked against real musl, rebuilt by the real wackywasm-tools toolchain — is named K7 (the U-series) and proposed in §11 below. This framing is **Option C from the K5-close scope decision**: K6 is the **first-fs-loaded-execve** milestone, not the **first-real-userland** milestone. The deliverable is the kernel-side surface; the payload stays K5-shape on purpose. Single-axis discipline (see §10 below) preserves the refutation-budget integrity the K-series has shown since K1. Status: K6 OPENER. Each of the seven enumerated framework sections (§§3-9) has a "K6 enforcement" subsection telling K6 implementers what must ship and what's allowed to land later. The sub-phase implementation sequence is captured in §13. -------------------------------------------------------------------------------- 1. Why this document exists separately -------------------------------------------------------------------------------- ``threading-model.rst`` answers "how do multiple Workers cooperate for a multi-threaded user process"; ``memory-model.rst`` answers "where does memory live"; ``sched-model.rst`` answers "how do tasks yield". None of them answer **"where does the first user binary come from"**. K5 sidestepped that question with an embedded ``hello-k5.wasm`` in ``.rodata`` and an ``arch_kernel_init_pre_run_init()`` override that bypassed ``kernel_init``'s standard ``/init`` iteration. That worked for K5's "first userspace via execve" deliverable but it is **not** upstream-faithful: a real Linux kernel reads ``/init`` from a real filesystem. K6 closes that gap. The question "where does the first user binary come from" has shape only when there's a backing filesystem; every assumption K5 baked in about an embedded image, about ``arch_kernel_init_pre_run_init``, and about ``binfmt_wasm`` returning ``-ENOEXEC`` is now a load-bearing constraint that K6 must either preserve or knowingly retire. Reading order: * If you are about to implement K6's initramfs bring-up: §3 (R1 initramfs), §6 (source-site enumeration of init/initramfs.c + fs/exec.c), §13 (K6-A1 sub-phase) are load-bearing on day one. * If you are about to implement K6's ``binfmt_wasm.load_wasm_binary`` real-read path: §4 (R2 + R3 + R7 — read, dispatch, post-execve handoff), §6 (source-site enumeration of fs/binfmt_elf.c as the shape-template), §13 (K6-B1+B2 sub-phases) are load-bearing. * If you are about to wire the K6-C end-to-end demo: §5 (R5 ``/init`` payload), §13 (K6-C1+C2 sub-phases), §14 (acceptance checklist) are load-bearing. * If you are about to design the K7 U-series: §11 (proposed K7 surface) and §10 (refutation-budget projection) are load-bearing. * If you arrived here just to understand the §20.5 / §20.6 K5-shipping amendments folded into K6 (tsc-gate, bootKernel default-spawn-handler): §12 has the amendment block. -------------------------------------------------------------------------------- 2. Scope decision — Option C (K5-close pin) -------------------------------------------------------------------------------- The K5-close scope decision named K6 as "filesystem completion only" with three explicit framings: * Option A: K6 = filesystem only; wackywasm-tools + real musl as parallel U-series starting in parallel; K6 demo uses libwacky binary on real fs. * Option B: K6 = filesystem + wackywasm-tools + real musl, bundled; K6 demo = real-musl binary on real fs. Largest K6. * **Option C (chosen)**: K6 = filesystem only; **the milestone story is "first fs-loaded execve, not first real userland"**; libwacky- on-fs is the **deliberate** end state, named that way to make the deferral explicit. wackywasm-tools + real musl moves to K7 = the U-series. Reasoning (pinned here in the spec so it can't drift later): * **Single-axis discipline.** K1 through K5 each closed with one conceptual surface in motion (boot, mem, sched, threading- foundation). Option B bundles two surfaces (filesystem + toolchain + musl) into one phase, breaking the pattern and re-introducing the multi-axis refutation surface the K-numbering was designed to avoid. * **Narrative honesty.** Option B's "first real userland" framing promises a payload milestone that the deliverable doesn't actually depend on. K6's value is the **infrastructure** (fs + exec + vfs + mm engagement), not whichever payload happens to ride on it. Option C names the deliverable for what it is. * **Refutation-budget integrity.** K5 closed at 0/≤1 against the ARCHITECTURE.md §20.9 chained recurrence. Option C inherits that trajectory; Option B's bundle would force a budget expansion to absorb both fs-surprises and toolchain-surprises, eroding the compounding gain. K7 then takes the U-series surface (§11 below), and K8+ opens the next single-axis phase (whichever — threading completion, signals, or real init system — is naturally next given K6+K7's end state). -------------------------------------------------------------------------------- 3. R1 — initramfs (kernel-side unpacking + rootfs population) -------------------------------------------------------------------------------- K6 boots a kernel that **unpacks a cpio-format initramfs into a real rootfs** during ``populate_rootfs()`` (upstream ``init/initramfs.c``), gives the result to ``mount_root()``, and lets ``kernel_init``'s standard ``/init`` iteration find a real file at ``/init``. **Upstream contract (do NOT modify).** Upstream's initramfs flow: :: start_kernel → rest_init → kernel_init (kthread) → kernel_init_freeable → populate_rootfs (unpacks __initramfs_start..__initramfs_end) → prepare_namespace OR (if rootfs has /init) skip → run_init_process iteration (/sbin/init, /etc/init, /bin/init, /bin/sh) The kernel either embeds the initramfs blob in vmlinux (via the upstream ``CONFIG_INITRAMFS_SOURCE`` linker-script hook between ``__initramfs_start`` and ``__initramfs_end``) or loads it from a bootloader-provided memory region (``initrd_start`` / ``initrd_end``). For wasm32, the natural fit is **HardwareJS supplies the initramfs bytes at boot** (analogous to how it supplies cmdline and boot_info today) and the kernel parses ``initrd_start`` / ``initrd_end`` as a fixed memblock region. **K6 enforcement.** (R1.a) HardwareJS-side: a new ``initramfs`` field on ``BootKernelOptions`` carrying a ``Uint8Array`` of cpio bytes. When present, HardwareJS writes the bytes into ``env.kernel_memory`` at an aligned offset and updates the ``wasm_boot_info`` struct's new ``initrd_offset`` / ``initrd_size`` fields. ABI bump from v1 → v2 (see §15 below for the ``wasm_boot_info`` struct evolution). (R1.b) Kernel-side ``setup_arch`` reads ``boot_info.initrd_offset``, calls ``initrd_start = phys_to_virt(initrd_offset)``-equivalent (on wasm32 the C pointer IS the offset, identity-mapped per ``memory-model.rst`` §1), ``initrd_end = initrd_start + initrd_size``, and lets ``init/initramfs.c::populate_rootfs`` discover the region via its standard ``unpack_to_rootfs(__initramfs_start, ...)`` and ``unpack_to_rootfs((char *)initrd_start, ...)`` calls. (R1.c) The unpacked filesystem lives in a **ramfs/tmpfs** instance (upstream does this automatically — ``init_rootfs`` and ``mnt_init`` set up ``rootfs`` as a tmpfs). No fs-driver work on the wasm32 side is required for R1 itself; the upstream code already drives ramfs/tmpfs through arch-agnostic paths. Verify by booting with an empty (header-only) cpio and observing ``/init`` lookup fail with ``-ENOENT`` (not with a fs-driver crash). (R1.d) The vitest acceptance shape: K6's boot test supplies a fixed ``initramfs`` Uint8Array containing exactly one file (``/init``) whose content is ``hello-k5.wasm``. The kernel unpacks, ``kernel_init`` finds ``/init``, dispatches to ``binfmt_wasm.load_wasm_binary``, the load succeeds, and the user Worker prints ``hello from K5 userspace\n``. -------------------------------------------------------------------------------- 4. R2 + R3 + R7 — binfmt_wasm.load_wasm_binary real-read, do_execve flow, arch_post_execve -------------------------------------------------------------------------------- K5-B3 landed ``binfmt_wasm.load_wasm_binary`` that **matched** WASM binaries but always **returned -ENOEXEC** after the match — the parser ran on ``bprm->buf`` (the first 256 bytes upstream pre-loads for every binfmt walk) but the actual file read was deferred. K5-C2 dispatched via an embedded image through ``wasm32_exec_image`` instead. K6 retires both shortcuts. **R2 — real kernel_read.** **Landed at K6-B4.** ``binfmt_wasm.load_wasm_binary`` reads the **full** file via ``kernel_read(bprm->file, buf, size, &pos)`` into a kmalloc'd buffer in env.kernel_memory; the kmalloc'd pointer's value (= the env.kernel_memory offset on wasm32) becomes the ``exec_image_offset`` of the spawn-ring FORK request. (The K6 opener originally specified ``kernel_read_file``; K6-B4 surfaced that ``kernel_read_file``'s ``deny_write_access(file)`` fails with -ETXTBSY when the initramfs unpacker's deferred ``fput()`` hasn't been task-work-run yet. ``kernel_read`` is the lower-level path that ``binfmt_elf`` itself uses via ``elf_read``, and ``bprm->file`` already has FMODE_EXEC + deny-writes applied via ``do_open_execat`` so the redundant guard is unnecessary at this call site. See §16.10 "§20.5 source-name drift (1)".) The K5 path through ``wasm32_exec_image(...)`` is retained as a **shared helper** called by both the ``arch_kernel_init_pre_run_init`` fallback path AND the new ``binfmt_wasm`` real-read path. The helper's signature stays: ``long wasm32_exec_image(const u8 *image, size_t size, const char *name)``. ``load_wasm_binary`` calls it with the kmalloc'd buffer; the existing K5 self-test continues to call it with the embedded buffer. **R3 — do_execve flow.** ``kernel_init``'s ``run_init_process("/init")`` flows through ``do_execve_common`` → ``open_exec`` → ``search_binary_handler`` → ``binfmt_wasm.load_wasm_binary``. Per the §6 source-site enumeration: ``do_execve_common`` does signal setup, fd-table inheritance, env+argv passing, cwd, etc. — all the upstream infrastructure K5-B3's design discussion called out as the reason for choosing Shape A (binfmt_wasm sits INSIDE do_execve's binfmt iteration). K6 finally exercises the full flow. **R7 — arch_post_execve handoff.** K5-C2's ``arch_kernel_init_pre_run_init`` parked ``kernel_init`` forever after the spawn dispatched. K6's path is different: the spawn dispatches inside ``binfmt_wasm.load_wasm_binary`` (called by ``do_execve``), then ``do_execve`` continues with its normal post-binfmt cleanup, and **at the end of do_execve** the arch hook detects the kthread-to-user-Worker transition and parks the calling task. The arch hook is named ``arch_post_execve`` (per K5-B3's design discussion); K6-B2 lands it as a weak no-op default in ``fs/exec.c`` plus a strong override in ``arch/wasm32/kernel/init.c``. The override's body: :: void arch_post_execve(struct linux_binprm *bprm) { if (bprm->binfmt == &wasm_format) { /* The execve transitioned this task to user-Worker * ownership. Park the kthread side; the user Worker * now owns this task's execution. * * K6 case 1: this is the kernel_init task transitioning * from kthread to first user process. Park forever * (same shape as K5-C2's park_kthread_forever). * * K6 case 2: a user process called execve. The task is * already user-side, NOT a kthread; we don't park, we * just let do_execve return cleanly. K6 has no such * caller (only kernel_init does execve at K6) but the * check keeps K7+ safe. */ if (current->flags & PF_KTHREAD) { park_kthread_forever(); } } } **K6 enforcement (this section specifically).** (R2) ``binfmt_wasm.load_wasm_binary`` reads the binary via ``kernel_read_file``; returns 0 on success (not ``-ENOEXEC``). (R3) ``kernel_init``'s ``run_init_process("/init")`` succeeds when the initramfs has a ``/init`` file containing a WASM binary. (R7.a) ``arch_post_execve`` hook added to ``fs/exec.c`` (weak default) via a new patch ``patches/0005-fs-add-arch_post_execve- hook.patch``. (R7.b) ``arch/wasm32/kernel/init.c`` adds the strong override. (R7.c) The K5-C2 ``arch_kernel_init_pre_run_init`` override is **retained** as a fallback — if the initramfs path fails (no ``/init`` found, or kernel_read_file fails), the embedded-image dispatch still works. K6 close demands the fallback path stays **operational** (verified by a fresh K6-C2 sub-test with empty initramfs) so K5 regression coverage isn't lost. -------------------------------------------------------------------------------- 5. R5 — /init payload (libwacky-built hello-k5) -------------------------------------------------------------------------------- K6's ``/init`` is the **same** ``wackywasm-tools/build/hello-k5.wasm`` that K5 embedded in vmlinux. The only thing that changes is where it lives: at K5 it's a static const array in ``.rodata``; at K6 it's a file inside the initramfs cpio that HardwareJS supplies at boot. This is the **deliberate** K6 end state per §2 Option C. The K7 U-series replaces the libwacky binary with a real-musl binary, without touching K6's fs/exec path — that's the cleanest possible K6/K7 handoff and the reason for the scope split. **K6 enforcement.** (R5.a) A new ``linux-wasm/scripts/build-k6-initramfs.sh`` script produces an ``initramfs.cpio`` containing one file (``/init``, mode 0755) whose contents are ``wackywasm-tools/build/hello-k5.wasm``. (R5.b) The K6 acceptance test loads the cpio bytes from disk and passes them to ``bootKernel({ initramfs: ... })``. (R5.c) The K5-C2 embedded image stays for the fallback path; K6 ``Makefile`` keeps the ``builtin-init-image`` target intact. -------------------------------------------------------------------------------- 6. Source-site enumeration (§20.6 — applied INLINE at K6 opener time) -------------------------------------------------------------------------------- Per ARCHITECTURE.md §20.6, every upstream code site K6 depends on gets grepped at opener time so the K6 implementation phase doesn't discover a "we didn't realize upstream did X" surprise. The list below was generated by ``rg`` against the wasm32-built Linux 6.12 tree as of K5-close. If any line changes in upstream 6.13+, K6 implementation MUST refresh this section (or surface a refutation if the upstream change invalidates a K6 design choice). **Initramfs unpacking (R1).** * ``init/initramfs.c::populate_rootfs()`` — single entry point; iterates ``__initramfs_start..__initramfs_end`` (linker-script symbols) then the bootloader-supplied ``initrd_start..initrd_end`` region. * ``init/initramfs.c::unpack_to_rootfs(buf, len)`` — cpio parser; takes a flat buffer pointer + length, walks cpio records, creates each file via ``vfs_mkdir`` / ``vfs_create`` / etc. Returns NULL on success, an error string on failure. * ``init/initramfs.c::write_buffer()`` / ``flush_buffer()`` — decompression path; only invoked if the first 4 bytes look like a compression magic. K6 ships uncompressed cpio for simplicity; K7+ may opt into gzip/xz. * ``init/main.c::kernel_init_freeable()`` — calls ``populate_rootfs()`` then ``prepare_namespace()`` (skipped if rootfs is non-empty, which initramfs makes it). * ``init/do_mounts.c::prepare_namespace()`` — skipped at K6 because populate_rootfs leaves a non-empty rootfs (initramfs unpack succeeded; ``/init`` exists). K7+ may want a real disk-backed fs; that work is K8+. **execve flow (R2, R3, R7).** * ``fs/exec.c::do_execve_common(filename, argv, envp)`` — the upstream execve entry. Builds ``struct linux_binprm``, opens the file, calls ``search_binary_handler(bprm)``, then does post-binfmt setup (``check_unsafe_exec``, ``free_bprm``). * ``fs/exec.c::search_binary_handler(bprm)`` — iterates ``formats`` linked list (``binfmt_misc``, ``binfmt_script``, ``binfmt_elf``, ``binfmt_wasm``). For each, calls ``fmt->load_binary(bprm)``. Stops at the first non-ENOEXEC return; logs missing-handler / returns ``-ENOEXEC`` if all decline. * ``fs/exec.c::open_exec(name)`` — opens the file from filename; populates ``bprm->file``. * ``fs/exec.c::prepare_binprm(bprm)`` — pre-reads ``BINPRM_BUF_SIZE`` bytes of the file into ``bprm->buf``. This is what K5-B3's ``load_wasm_binary`` already uses for magic matching. K6 keeps that path AND additionally reads the full file via ``kernel_read_file`` for the payload. * ``fs/exec.c::begin_new_exec(bprm)`` — replaces the calling task's mm/files/signal/cwd state per the new binary. **K6 question: does ``binfmt_wasm.load_binary`` call ``begin_new_exec``?** Per K5-B3 doc, the K5 implementation deferred this. K6 must call it — otherwise the kthread→user-Worker handoff in ``arch_post_execve`` runs against an inconsistent task state. * ``fs/exec.c::kernel_read_file(file, ...)`` — reads an entire open file into a kmalloc'd buffer. Returns the size or a negative errno. **K6's binfmt_wasm uses this.** * ``fs/exec.c`` ``arch_post_execve`` — **landed at K6-B2** via patch ``0005-fs-add-arch_post_execve-hook.patch``. Weak default no-op (same shape as patch 0004's arch_kernel_init_pre_run_init). Call site is the tail of ``bprm_execve()``'s success path, after the standard post-execve teardown. See ``rootfs-model-source-snapshots.txt`` for current line numbers (snapshot is regenerated whenever patches/0005 context shifts). **binfmt-format reference (R2).** * ``fs/binfmt_elf.c::load_elf_binary(bprm)`` — upstream ELF loader. Shape K6's binfmt_wasm.load_wasm_binary mirrors: validate header → kernel_read_file for full payload → set up new mm → begin_new_exec → setup_new_exec → install_exec_creds → set up stack/auxv → arch-specific entry (jumping to ``e_entry`` for ELF; submitting spawn-ring request for WASM) → return 0. * ``fs/binfmt_elf.c`` lines ~700-900 covering the read-file + setup_new_exec sequence — read at K6 opener time as the shape template; deviations from this shape are surface for K6 inline-enumeration probes. **Output of `rg` for live confirmation (refresh at K6 implementation time):** :: $ rg -n "kernel_read_file\b" linux-wasm/linux/fs/exec.c | head -5 $ rg -n "begin_new_exec\b" linux-wasm/linux/fs/exec.c | head -5 $ rg -n "unpack_to_rootfs\b" linux-wasm/linux/init/ | head -5 $ rg -n "populate_rootfs\b" linux-wasm/linux/init/ | head -5 K6 sub-phase implementers MUST run those four commands and snapshot the output into a follow-up doc (``rootfs-model-source-snapshots.txt``) so the rest of K6 can refer back to specific line numbers without re-grepping. Same shape as K5's source-snapshots.txt practice. -------------------------------------------------------------------------------- 7. Toolchain-semantic probes (§20.5 — applied INLINE at K6 opener time) -------------------------------------------------------------------------------- K5 introduced T1/T2/T3 probes to pin SharedArrayBuffer cross-Worker semantics, ``memory.atomic.wait32/notify`` substrate, and exported-mutable-global setter visibility. K6 introduces two new toolchain-semantic invariants that load-bearing for the fs path, each pinned by a probe: **T4 — cpio binary-layout invariance.** The kernel's ``init/initramfs.c::unpack_to_rootfs`` parses a binary cpio format defined by ``Documentation/early-userspace/buffer- format.rst`` (upstream). Subtle: cpio has multiple variants (old, new, crc, newc); Linux supports only **newc** (``070701``) and **crc** (``070702``) in initramfs. Other variants are silently rejected. K6's ``scripts/build-k6-initramfs.sh`` must emit newc-format cpio. The probe T4 constructs a synthetic newc cpio with one file in JS, hands it to a small test that calls a kernel-side ``wasm32_test_unpack_cpio(buf, len)`` exported helper, and asserts unpack succeeds. Failure shape: * Probe fails → K6's build-k6-initramfs.sh is emitting a non-newc variant. Surface immediately; fix the script. * Probe succeeds but real K6 boot fails ``/init`` lookup → populate_rootfs is dropping the file via a vfs/mount issue upstream of cpio. Distinct refutation surface. T4 deliverable: ``hardwarejs/test/k6-cpio-probe.test.ts`` plus a kernel-side ``wasm32_test_unpack_cpio`` export from ``arch/wasm32/kernel/initramfs_probe.c``. **T5 — kernel_read_file readback shape.** K5-B3 documented that on wasm32 the C pointer value IS the env.kernel_memory offset (identity-mapped). K6's binfmt_wasm relies on this for the kernel_read_file → spawn-ring handoff: the kmalloc'd buffer's address gets passed to HardwareJS as a ``u32 exec_image_offset``. The probe T5 verifies the round trip: 1. Kernel-side: allocate a buffer via ``kmalloc(N, GFP_KERNEL)``, write a sentinel pattern, expose its address as a u32 export. 2. HardwareJS-side: read the bytes at ``env.kernel_memory[offset]`` and confirm the sentinel pattern matches. This catches a class of toolchain regressions where kmalloc- returned pointers stop matching env.kernel_memory offsets (e.g., if the kernel ever moves to a non-identity address-space layout for kernel allocations). The K5 design didn't include this probe because K5's exec_image was a static const array whose offset was known at link time. K6 introduces dynamic kmalloc into the exec_image path; the probe pins the invariant. T5 deliverable: ``hardwarejs/test/k6-kmalloc-probe.test.ts`` plus a kernel-side ``wasm32_test_kmalloc_export`` export from ``arch/wasm32/kernel/kmalloc_probe.c``. **T-series numbering convention.** T1-T3 are threading-model.rst probes; T4-T5 are rootfs-model.rst probes. T-rows are per-document, not project-global. Future K-phase openers add their own T-rows. -------------------------------------------------------------------------------- 8. Defer conditions (§20.7 — phase-dependency annotations) -------------------------------------------------------------------------------- Items NOT in K6 scope, with explicit "OK to defer iff …" verifications: **(D1) wackywasm-tools + real musl arch port (K7 = U-series).** K6 ships with the K5-built libwacky hello-k5 as ``/init``. Real musl is K7. Verification: K6 ``/init`` is byte-identical to K5's embedded image; the K6 acceptance test's stdout is character-identical to the K5-C2 test's stdout ("hello from K5 userspace\n"). **(D2) pthread_create / futex / multi-threaded musl (K8+).** K6 ``/init`` is single-threaded by construction (the libwacky binary's ``pthread_create`` stub returns ``-ENOSYS``). Verification: the FORK request submitted by K6's binfmt_wasm path always has ``mode = WASM_SPAWN_FORK``; no THREAD-mode requests appear in the boot. **(D3) signals (kill / SIGCHLD / SIGTERM etc.) (K8+).** K6's user Worker exits cleanly via exit_group(0); no signal-driven termination. Verification: the ``hardwarejs/src/kernelSpawnHandler.ts`` syscall router still returns ``-ENOSYS`` for any signal-related syscall (kill, sigaction, rt_sigprocmask, etc.); no K6 test path exercises any of them. **(D4) Real init system (systemd / OpenRC / busybox init) (K8+).** K6's ``/init`` is hello-world-shaped; no fork(), no exec() of secondary binaries. Verification: the FORK request count observed by the spawn-ring consumer is exactly 1 per boot. **(D5) Real disk-backed filesystem (ext4, fat, etc.) (K8+).** K6 uses initramfs (ramfs) only; no block device driver, no fs/ext4, no disk I/O. Verification: kernel boot does not attempt any ``mount`` of a real block device beyond what upstream's ``prepare_namespace`` skips. **(D6) /proc + /sys (K7+).** K6's ``/init`` does not read /proc or /sys; the initramfs has no /proc or /sys mount points. Verification: K6 acceptance test sees no syscalls to open(/proc/...) or open(/sys/...). If any of D1-D6 turns out to be K6-required (test discovers ``/init`` needs it), that's a refutation: K6 underestimated its surface novelty and the budget reasoning needs to extend. -------------------------------------------------------------------------------- 9. K6-required (R1-R7 summary) -------------------------------------------------------------------------------- (R1) Initramfs unpacking — HardwareJS supplies cpio bytes; ``wasm_boot_info`` v2 carries initrd_offset/size; arch/wasm32 populates ``initrd_start``/``initrd_end`` for upstream ``init/initramfs.c::populate_rootfs`` to discover. (R2) ``binfmt_wasm.load_wasm_binary`` reads the full file via ``kernel_read_file``; calls ``begin_new_exec`` and the rest of the upstream binfmt setup; submits FORK spawn request from the kmalloc'd buffer; returns 0. (R3) ``kernel_init`` reaches ``run_init_process("/init")`` successfully; ``/init`` is opened and the binfmt walk dispatches to ``binfmt_wasm``. (R4) ``arch_kernel_init_pre_run_init`` (K5-C2) is retained as a fallback path. K6 boot with empty initramfs falls through to the embedded image and still succeeds (the demo's "robust boot" property). (R5) ``/init`` payload is libwacky-built hello-k5 (per §2 Option C scope choice). Bit-identical to K5's embedded image. (R6) Spawn handler is single-callsite; no THREAD-mode requests (per D2). (R7) ``arch_post_execve`` hook in ``fs/exec.c`` (weak default) with strong override in ``arch/wasm32/kernel/init.c``. The override parks kernel_init's task when a ``binfmt_wasm`` execve completes from kthread context. Each (R1)-(R7) gets at least one sub-test in ``hardwarejs/test/k6-*`` per §20.6. -------------------------------------------------------------------------------- 10. Refutation budget (per ARCHITECTURE.md §20.9) -------------------------------------------------------------------------------- **K6 declared budget: ≤ 2 refutations during implementation.** Reasoning per ARCHITECTURE.md §20.9.1 three-input formula: * **Prior-phase actual count.** K5 closed at 0 refutations against ≤1 budget. Trajectory is favorable; the K5 §9/§10/§11 discipline-compounding adjustment is empirically vindicated. * **Discipline-compounding adjustment.** K6 inherits K5's full §20 discipline kit (§9 source-site enumeration; §10 toolchain-semantic probes; §11 defer conditions; §20.5/§20.6 amendment shapes). All applied inline above. K6 contributes no new discipline shapes; only new applications. * **Surface-novelty adjustment.** +1 to +2. K6 brings up: * Three new upstream subsystems engaged (``fs/exec.c``, ``init/initramfs.c``, ``fs/binfmt_elf.c`` as shape-template). * Two new arch hooks (``arch_post_execve`` patch 0005; cpio initramfs population in ``setup_arch``). * One ABI evolution (``wasm_boot_info`` v1 → v2 with initrd fields). * One new build-pipeline piece (``build-k6-initramfs.sh`` cpio emitter). These are honest new surface. The +1-to-+2 range is the estimated probability of a tactical bug or tool-semantic surprise that the §6 + §7 inline-enumeration didn't catch in advance. Result: 0 − 0 + 1..2 = 1..2, rounded to **≤ 2**. The budget can be spent in any §20.5/§20.6/§20.7/§20.8/§20.9 shape; the count is post-classification (per K5's pattern, §20.5/§20.8 amendments don't count, only §20.9-shaped genuine contract refutations do). The K6-close commit body records actual + budget + classification of each find, same as K5's close commit. -------------------------------------------------------------------------------- 11. K7 — proposed U-series surface (real musl arch port) -------------------------------------------------------------------------------- .. note:: **K7 opener (post-K6-close) AMENDED this section's surface.** K7 absorbs thread-mode bring-up (Regime 1b) into its scope as an explicit dual-axis K-phase. The amended K7 scope is the spec at ``Documentation/wasm/toolchain-model.rst``; the proposal below is preserved for historical comparison but is superseded. Specifically, K7-U4 (thread-mode bring-up) was NOT in this section's proposal — it was a "K8+" deferral. The K7-opener message at K6 close folded it in for the reasons documented in ``toolchain-model.rst §2``. Per K5-close scope decision (§2), K7 is the U-series: bring up real musl + wackywasm-tools so that future K-phase userspace binaries link against a standards-compliant libc. **Original (pre-K7-opener) proposed K7 surface — superseded by toolchain-model.rst.** * **K7-U1**: ``wackywasm-tools`` toolchain hardening. The ``wackywasm-tools/bin/wasmcc``, ``wasmld``, ``wasmar``, ``wasmrun`` wrappers were already present at K5 and used to build hello-k5 (with the libwacky stub). K7-U1 verifies the toolchain handles a real-musl build: full ``configure``, full ``musl/arch/wasm32`` port (replacing K5's libwacky stubs with real musl source), full musl static link. * **K7-U2**: real musl 1.2.x ``arch/wasm32`` port. ``wackywasm-tools/musl-src/arch/wasm32/*.h`` evolves from the K5 hello-world stubs (``crt1.c``, ``runtime.c``, ``pthread_stub.c``) to real musl source-tree integration: ``syscall_arch.h``, ``pthread_arch.h``, plus the arch-specific ASM files (``wasm_thread.S`` already exists from K5-C1; K7 adds the rest). * **K7-U3**: rebuild ``hello-k5`` against real musl. The binary remains hello-world shaped; the only thing that changes is the libc behind ``puts()``. K7-U3 close: the rebuilt ``hello-k5.wasm`` boots through K6's fs path and prints "hello from K5 userspace\n" character-identically. * **K7-U4**: stretch — first real-musl binary that does something K5/K6 couldn't (e.g., uses ``printf`` with format strings, or reads ``/etc/hostname`` if K8+ adds it). Optional; not gating K7 close. **K7 deliverables (close criteria).** (U1) wackywasm-tools/bin/* wrappers handle a real musl build without modification. (U2) ``wackywasm-tools/musl-src/`` contains a complete wasm32 arch port that ``musl-1.2.5/configure --target=wasm32`` accepts and ``make`` builds. (U3) ``hello-k5.wasm`` rebuilt against real musl is byte- different from K5/K6's libwacky version (it goes through real musl's printf/puts/write rather than libwacky's hand-rolled ones) but **functionally identical** at the syscall level — the FORK request, the write(1, ...) syscall, the exit_group(0) all happen in the same order with the same args. (U4) K6's acceptance test, re-run with the K7-rebuilt /init, passes character-identically (stdout, exit code, dmesg markers). **K7 refutation budget projection.** ≤ 2 if K6 closes at 0-1. The U-series surface is bounded (toolchain + libc port; no upstream-kernel work), so the budget shouldn't need to grow beyond K6's. The "real" projection happens in the K7 opener once K6 actuals are known. **K8+ deferral pinned.** After K7 closes with real-musl /init AND thread-mode bring-up (per the K7 opener's Option 2 absorption), K8 opens the next axis. ``toolchain-model.rst §12`` enumerates four K8 candidates (signals, initcall-debt repayment, userspace expansion, real init system); the agent's lean is (a) signals, the natural threading-companion work. K8 scope is pinned in the K7-close commit body. The pre-K7-opener proposal here ("K8 = threading completion") is partially superseded by K7-U4: K7 now ships pthread_create + futex + multi-threaded musl + the BUG_ON removal. K8 picks up where K7 leaves off (signal delivery into pthreads, the remaining threading-companion work). -------------------------------------------------------------------------------- 12. K6 opener — folded-in §20 amendments -------------------------------------------------------------------------------- Two K5-shipping finds surfaced during the prestrike-web demo integration after K5-close. Both classified as §20.5 (tool- semantic or footgun-shape; NOT §20.9 refutations of contract). Folded into the K6 opener as design-time amendments so K6 implementation inherits them. **§12.α — tsc --noEmit acceptance gate (§20.5).** K5 vitest passed but ``tsup``'s DTS phase failed on two strict-mode errors invisible to the transpile-only vitest: * ``bootKernel.ts:219`` — ``as SharedArrayBuffer`` rejected because TS ≥5.4 distinguishes ``ArrayBuffer`` vs ``SharedArrayBuffer`` via ``Symbol.toStringTag``. Workaround: ``as unknown as SharedArrayBuffer``. * ``spawnRingConsumer.ts:311`` — ``Atomics.waitAsync`` not in ``tsconfig.json``'s ``lib``. Workaround: add ``ES2024`` or ``ES2024.Atomics`` to ``lib``. Both invisible to vitest because vitest transpiles, doesn't type-check. The K5 acceptance gate ("``pnpm test`` clean") didn't catch them. **Fix at K6 opener time:** * ``hardwarejs/package.json`` gains a ``verify`` script that runs ``tsc --noEmit && vitest run``. * Top-level ``Makefile`` gains a ``hwjs-verify`` target invoking ``pnpm verify``. * K6+ acceptance criterion adds: ``make hwjs-verify`` clean. The ``make hwjs-test`` shorthand (vitest only) stays for fast inner- loop iteration; ``hwjs-verify`` is the gate. * Pre-existing K5 type errors fixed at opener time (test files needing ``Uint8Array`` annotations rather than unrestricted ``Uint8Array``; the K3 mutator callback's TypeScript control-flow narrowing worked around via a holder-object pattern). All commits to source pre-K6 implementation work; the K6 opener commit body records the audit summary. **§12.β — bootKernel default-spawn-handler footgun (§20.5).** K5 ``bootKernel()``'s default ``spawnHandler`` (when caller supplied none) returned ``-ENOSYS``. For K5+ kernels this means **demo clients that don't supply a handler silently regress to K4 behavior**: the kernel boots, posts the spawn-ring-offset, submits the FORK request for the embedded hello-k5, gets ``-ENOSYS``, and parks. Outwardly looks identical to the K4 "No working init" panic. prestrike-web's ``LaunchMachine.svelte`` hit this. Same test-shape-catches-contract-drift pattern as the K5-C2 spawn-ring tail-owner bug (§20.6 amendment): K5 vitest exercised with a test-constructed handler; production default diverged. **Architectural decision (K6 opener):** The K6 ``bootKernel()`` shape implements a **three-mode resolution matrix**: 1. ``spawnHandler`` supplied: that handler is used verbatim (K5 test shape). 2. ``spawnHandler`` undefined + new ``userWorkerEntry`` option supplied: bootKernel **default-constructs** the handler via ``makeKernelSpawnHandler({...})`` (K6+ demo-client shape). 3. ``spawnHandler`` undefined + ``userWorkerEntry`` undefined: warn-once stub returning ``-ENOSYS``. The ``console.warn`` on first request makes the regression visible without breaking pre-K5 callers (K4-compat shape). The decision pins to "default-construct when userWorkerEntry is supplied, warn-once stub otherwise". The intermediate "always default-construct" was rejected because it requires ``userWorkerEntry`` to default to something, and no sensible default exists across node/browser/Web Worker/Node Worker. Implementation lands at K6 opener time alongside the doc (file: ``hardwarejs/src/bootKernel.ts``; test: ``hardwarejs/test/k6-bootkernel-spawn-defaults.test.ts``). **§12.γ — DBG cleanup audit (clean — nothing to remove).** Audit performed at K6 opener time for K4-era ``DBG`` pr_info lines (``DBG fork``, ``DBG enq``, ``DBG cmpl``, ``DBG sto``, ``DBG rewind``, ``DBG yield``). Result: zero matches in source, zero matches in current boot transcripts. Either an earlier cleanup-agent succeeded or the lines never made it into a committed snapshot. The K6 opener inherits a clean dmesg. All remaining ``pr_info`` / ``pr_warn_once`` / ``WARN_ONCE`` in arch/wasm32 are either load-bearing boot markers (vitest asserts against several of them), one-shot informational prints, or intentional debug infrastructure firing only on unexpected control flow. None are removable noise. Audit matrix at K5-close commit body. -------------------------------------------------------------------------------- 13. Sub-phase reading order (K6 implementation sequence) -------------------------------------------------------------------------------- Implementers MUST read sub-phases in order. Each sub-phase's work is constrained to its own surface; cross-sub-phase work gets surfaced as a refutation, NOT silently bundled. **K6-A — probes + scope-snapshot (opener day).** (A1) ``tools/k6-rootfs-model-probe/`` containing T4 (cpio unpack) and T5 (kmalloc → env.kernel_memory readback). Vitest: ``hardwarejs/test/k6-cpio-probe.test.ts``, ``hardwarejs/test/k6-kmalloc-probe.test.ts``. (A2) Snapshot the §6 source-site enumeration into ``rootfs-model-source-snapshots.txt``. Driven by ``linux-wasm/tools/k6-rootfs-model-probe/snapshot-sources.sh``: the ``rg`` queries are codified there (byte-deterministic output, sorted, date-only timestamp). Output is committed. Drift between this snapshot and the upstream tree at K6-B time is either spec drift (refresh §6 + re-run) or genuine upstream movement (note the diff, refresh both). **K6-B — kernel-side fs path.** (B1) ``wasm_boot_info`` v1→v2 with ``initrd_offset``, ``initrd_size`` fields. C ``static_assert`` pins layout; JS mirror in ``hardwarejs/src/spawn-ring-abi.ts``-equivalent for boot-info pins layout. ``hardwarejs/src/bootKernel.ts`` writes the initramfs bytes into env.kernel_memory and fills the new fields. (B2) ``patches/0005-fs-add-arch_post_execve-hook.patch`` — upstream ``fs/exec.c`` gains weak ``arch_post_execve()``; patches/0004 retained for the fallback path. (B3) ``arch/wasm32/kernel/setup.c`` reads ``boot_info.initrd_offset`` / ``initrd_size``, sets up ``initrd_start`` / ``initrd_end`` global symbols (their address is what ``init/initramfs.c::populate_rootfs`` reads). (B4) ``arch/wasm32/kernel/binfmt_wasm.c::load_wasm_binary`` becomes a **real** loader: validates magic + version, ``kernel_read_file`` for the full payload, ``begin_new_exec``, ``setup_new_exec``, ``install_exec_creds``, submits the spawn request via ``wasm32_exec_image``, returns 0. K5's ``-ENOEXEC`` return after match becomes a code-path that fires only on malformed-but-magic-matching binaries. (B5) ``arch/wasm32/kernel/init.c::arch_post_execve`` strong override (per §4 R7). **K6-C — end-to-end demo.** (C1) ``linux-wasm/scripts/build-k6-initramfs.sh`` — produces ``initramfs.cpio`` containing libwacky hello-k5 at ``/init``. Single output file; idempotent. (C2) ``hardwarejs/test/k6-fs-init.test.ts`` — boots vmlinux with a supplied initramfs containing hello-k5 as /init, verifies the boot dmesg reaches the new R1-R7 markers, asserts the user Worker spawned via the fs path (NOT via the arch_kernel_init_pre_run_init fallback), and confirms "hello from K5 userspace\n" reaches onUserOutput. (C3) ``hardwarejs/test/k6-fs-fallback.test.ts`` — boots vmlinux with an empty initramfs (cpio header but no /init file); asserts the kernel falls through to the K5-C2 arch_kernel_init_pre_run_init embedded-image path; asserts "hello from K5 userspace\n" still surfaces (regression coverage for the K5 path). **K6-D — sub-test audit.** (D1) Audit ``hardwarejs/test/k6-*`` against R1-R7. Map each R-row to a sub-test by file:line citation. Anything unrecited is a §20.6 discipline violation. (Same shape as K5-D.) (D2) Refresh ``Appendix A`` checklist (§14 below) with file paths + test names. Commit the populated checklist as part of the K6-close commit body. -------------------------------------------------------------------------------- 14. Appendix A — Quick-reference checklist for K6 implementers -------------------------------------------------------------------------------- Before declaring K6 close, verify each item below has a sub-test in ``hardwarejs/test/`` and a citation in the K6-close commit body. [x] §3 R1 HardwareJS bootKernel accepts ``initramfs: Uint8Array``; wasm_boot_info v2 carries initrd_offset/size; arch populates ``initrd_start``/``initrd_end`` (and ``arch_kernel_init_pre_run_init`` bridges the missing initcall dispatch by calling ``unpack_to_rootfs`` directly — §15 row, see §16.6(c)). **Closed at K6-B1** via ``hardwarejs/test/k6-b1-bootinfo-v2.test.ts`` (sub-tests A, B, C all pass). [x] §6 Source-site snapshots committed as ``rootfs-model-source-snapshots.txt``. **Closed at K6-A2** via ``tools/k6-rootfs-model-probe/snapshot-sources.sh``. [x] §7 ``tools/k6-rootfs-model-probe/`` T4/T5 all pass. **Closed at K6-A1** (T4, T5 in kernel-side probes) and **K6-B1** (T4' end-to-end via JS-supplied cpio). [x] §4 R2 ``binfmt_wasm.load_wasm_binary`` reads via ``kernel_read``; returns 0 on success. **Closed at K6-B4** via ``hardwarejs/test/k6-b4-binfmt-wasm-loader.test.ts`` (probe-boot: cpio ``/init`` = hello-k5.wasm → kernel_execve(/init) → binfmt_wasm load_complete + user-Worker "hello from K5 userspace"). Spec drift from ``kernel_read_file`` → ``kernel_read`` documented in §16.10. [x] §4 R3 ``kernel_init`` reaches a do_execve(/init) successfully against an initramfs containing a WASM ``/init``. **Closed at K6-C2**. Caller is ``arch_kernel_init_pre_run_init`` rather than the upstream-canonical ``kernel_init → run_init_process(ramdisk_execute_command)`` because the wasm32 §15 "no initcall dispatch" row clobbers ramdisk_execute_command pre-arch-hook; see §16.13. Functional acceptance (binfmt_wasm engaged via real do_execve, spawn-ring delivered, hello-k5 output reaches user-Worker stdout, arch_post_execve parks kthread) is met. [x] §4 R7.a ``arch_post_execve`` weak hook in ``fs/exec.c`` (patch 0005). **Closed at K6-B2** (weak default lands; ``hardwarejs/test/k6-b2-arch-post-execve.test.ts`` asserts callable + no-op). [x] §4 R7.b ``arch_post_execve`` strong override in ``arch/wasm32/kernel/init.c`` parks kthread context when ``current->mm->binfmt == &wasm_format``. **Closed at K6-B5** via the K6-B4 vitest's updated assertions (the parking dmesg ``wasm32: arch_post_execve parking kthread for pid=...`` appears; the regression-marker ``K6-B4-PROBE: kernel_execve returned 0`` does NOT). K6-B2 sub-test A (no-op when binfmt is non-wasm) continues to pass. [x] §4 R4 K5-C2 ``arch_kernel_init_pre_run_init`` fallback still operational; K6-C3 fallback test passes. **Closed at K6-C3** via ``hardwarejs/test/k6-c3-fs-fallback.test.ts`` (empty TRAILER-only cpio → kern_path(/init)=-ENOENT → K5-C2 builtin-init dispatch → hello-k5 stdout). [x] §5 R5 ``/init`` payload is libwacky hello-k5 (bit-identical to K5 embedded image). ``build-k6-initramfs.sh`` ships. **Closed at K6-C1** via ``linux-wasm/scripts/build-k6-initramfs.sh`` + ``make -C linux-wasm k6-initramfs`` target. Output is byte-deterministic (mtime=0, fixed inodes, uid/gid=0): same input bytes → same SHA256, suitable for snapshot-testing in K6-C2/C3. [x] §8 D1-D6 deferral conditions verified by sub-tests. **Closed at K6-D1**: §8's deferrals (no THREAD-mode spawn requests, single binfmt walker callsite, single FS_REQUIRES_DEV, no execve from a non-init task, /init found via vfs rootfs only, no wackywasm-tools userspace) are structural — every K6 test exercises only kernel_init's task context, only binfmt_wasm (no other binfmts registered), and only K5's hello-k5 binary. The K6 C-side surface does not contain THREAD-mode submission code or multi-binfmt iteration. §8's R6 spawn-handler- single-callsite is covered by ``hardwarejs/test/k6-bootkernel-spawn-defaults.test.ts``. [x] §11 K7 = U-series surface confirmed (or amended) in K7 opener; this section's proposal is the input. **Pinned at K6 opener**: K7 opens against §11's U1..U4 sequence (wackywasm-tools toolchain, then arch/wasm32 musl port, then hello-k5 rebuilt against real musl, then optional stretch). Re- confirmation lands at K7 opener-write time; K6 close honors the K6-side commitment. [x] §12.α ``make hwjs-verify`` passes at K6 close. **Closed at K6-D2** (this commit). 19 test files pass, 58 tests pass, 2 skipped. [x] §12.β ``bootKernel`` three-mode handler-resolution matrix verified at K6-opener-time via ``hardwarejs/test/k6-bootkernel-spawn-defaults.test.ts``. **Closed at K6 opener** (pre-implementation); ``hwjs-verify`` includes it and it passes at K6 close. [x] §12.γ DBG-output audit clean (no source-side DBG strings; no boot-output DBG lines). **Closed at K6 opener** (DBG audit baked into the K6 opener commit per the standing-note discipline; ``rg -i 'dbg' linux-wasm/ wasm32-port/`` shows no source-side DBG markers and no test-side dmesg assertions on DBG strings). Any unchecked item is a §20 discipline violation; landing K6 with one is a refutation owed to a future HISTORICAL NOTE in this document. -------------------------------------------------------------------------------- 15. wasm_boot_info v1 → v2 ABI evolution -------------------------------------------------------------------------------- K6-B1 adds initramfs delivery via two new fields. The struct gains v2 ``abi_version`` so v1 callers hitting a v2 kernel are immediately observable. .. note:: The K6 opener's original §15 listed a simplified mental-model struct (7 fields, 56 bytes, magic ``0xB007B007``) that was meant as exposition, not as the actual upstream surface. The real struct shipped at K2 is already 96 bytes with 15+ fields and magic ``0x31494257`` (ASCII ``WBI1``). The amendment in §16.6 below documents this drift as a §20.5 source-name reconciliation; the rest of §15 has been rewritten to mirror the real layout. The real struct (single source of truth: ``arch/wasm32/include/asm/boot.h``): :: /* wasm_boot_info v1 (K2..K5), 96 bytes total, __packed. */ struct wasm_boot_info { __le32 magic; /* 0x31494257 'WBI1' */ __le32 abi_version; /* 1 */ __le32 struct_size; /* 96 */ __le32 flags; /* 0 */ __le64 total_memory; __le64 usable_start; __le64 usable_end; __le64 kernel_image_start; __le64 kernel_image_end; __le32 cmdline_offset; __le32 cmdline_length; __le32 num_cpus; __le32 boot_cpu_id; __le64 host_timer_freq_hz; __le32 reserved[4]; /* zero in v1; nonzero rejects */ }; /* wasm_boot_info v2 (K6-B1+), 96 bytes total, __packed. * Diff vs v1: abi_version 1→2, plus two u32s reclaimed * from reserved at offsets 80..87. sizeof unchanged. */ struct wasm_boot_info { /* ... bytes 0..79 identical to v1 ... */ __le32 initrd_offset; /* NEW byte 80: env.kernel_memory * offset of the cpio bytes, or 0 */ __le32 initrd_size; /* NEW byte 84: byte length, or 0 */ __le32 reserved[2]; /* shrinks from u32[4] to u32[2] */ }; K6-B1 implementation choices: * **Strict version match.** ``setup.c::wasm_validate_boot_info`` panics on any ``abi_version`` other than the ``WASM_BOOT_INFO_ABI_VERSION`` the kernel was built against (2 at K6-B1). The opener originally proposed v2 kernels accepting v1 callers as a forward-compat path; we chose strict match instead, because both sides bump in lockstep and no current demo client needs the back-compat slack. A §15 row to revisit if a real demo cannot be updated. * **Disjointness checks.** When ``initrd_size > 0``, the validator additionally panics if the initrd window overlaps the kernel image, extends past ``total_memory``, or overlaps the memblock window. See ``Documentation/wasm/boot-protocol.rst`` §4 for the rejection table. * **C ``static_assert`` pins.** ``asm/boot.h`` asserts ``sizeof(struct wasm_boot_info) == 96`` AND ``offsetof(..., initrd_offset) == 80`` AND ``offsetof(..., initrd_size) == 84`` AND ``offsetof(..., reserved) == 88``. Any layout drift fails the build. * **TypeScript mirror.** ``hardwarejs/src/boot-info-abi.ts`` exports ``WASM_BOOT_INFO_ABI_VERSION``, ``BOOT_INFO_V2_SIZE``, and each field offset as named constants. ``hardwarejs/src/kernelWorker.mjs`` writes the struct using the same offsets (duplicated with cross- reference comments because ``.mjs`` Worker entries cannot import ``.ts`` modules at runtime); the K6-B1 vitest cross-checks both sides. * **wasm32 initcall dispatch is broken (§15 row).** The upstream ``rootfs_initcall(populate_rootfs)`` never runs on wasm32 because ``__initcall*_start/end`` symbols are 0-imports. K6-B1's workaround is to call ``unpack_to_rootfs`` directly from ``arch_kernel_init_pre_run_init`` (the K5-C2 arch hook). This is sufficient for K6 acceptance; a generic initcall-dispatch shim is a future K-phase concern. -------------------------------------------------------------------------------- 16. HISTORICAL NOTES (refutations and amendments recorded here) -------------------------------------------------------------------------------- 16.1 K6-A1 amendment (§20.5 spec clarification) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ §7's T4 was originally specified as "the probe constructs a synthetic newc cpio with one file in JS, hands it to a small test that calls a kernel-side ``wasm32_test_unpack_cpio(buf, len)`` exported helper, and asserts unpack succeeds". The K6-A1 implementation compresses that to "kernel-embedded synthetic cpio + kernel parses": the cpio bytes are generated by ``tools/k6-rootfs-model-probe/build-k6-a1-cpio.sh`` (GNU cpio 2.13) into a committed C header ``arch/wasm32/kernel/k6_a1_probe_cpio.h``, and the kernel calls ``unpack_to_rootfs()`` directly on that buffer. Rationale: the JS→kernel byte handoff requires the ``wasm_boot_info`` v2 plumbing (§3 R1.a + §15) that itself is K6-B1 scope. Defining T4 to require v2 would either invert the K6-A1/K6-B1 dependency order or duplicate the v2 work at K6-A1. The kernel-side substrate question that T4 actually asks — "does the kernel's cpio parser correctly handle a valid newc archive" — is identical regardless of where the bytes originate. The kernel-embedded variant exercises the same parser code path the JS-supplied variant will exercise at K6-B1. K6-B1 adds an end-to-end T4' (in the vitest test that also exercises wasm_boot_info v2) which builds the cpio in JS, writes it via the v2 ``initrd_offset/size`` channel, and verifies the kernel reaches the same K6-PROBE-T4-style dmesg shape. T4 and T4' together cover both the kernel-parser substrate (K6-A1) and the JS→kernel byte-transport substrate (K6-B1). Classified as a §20.5 spec clarification (not a contract refutation): the property being verified is unchanged; only the mechanism is compressed. 16.2 K6-A1 patches/0006 + 0007 (§20.5 toolchain-semantic amendments) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Two upstream-patch deltas needed to make ``CONFIG_BLK_DEV_INITRD=y`` build under the wasm32 toolchain: * **patches/0006-init-expose-unpack_to_rootfs-for-arch-probes**: removes the ``static`` qualifier from ``init/initramfs.c::unpack_to_rootfs()`` and adds a new header ``include/linux/initramfs.h`` declaring the prototype. Required for arch probe code to invoke the parser on a buffer that is not at ``__initramfs_start`` or ``initrd_start``. * **patches/0007-usr-initramfs_data.S-wasm-friendly-section-syntax**: three wasm-clang-assembler adaptations to ``usr/initramfs_data.S``: (a) ``,"a"`` → ``,"",@`` section flag syntax matching what arch/wasm32's own .S files use; (b) ``.incbin`` removed (wasm assembler does not support it; the upstream-embedded ``__initramfs_*`` blob is left empty on wasm32, with the real initramfs flowing through ``initrd_start/end`` at K6-B); (c) explicit ``.size`` directives added (wasm-clang requires every data symbol to declare its size). Both classified as §20.5 toolchain-semantic adaptations (not contract refutations): the upstream behaviour stays correct, only the assembler-syntax surface changed to accommodate a different target's accept set. 16.3 K6-A1 close — refutation count vs budget ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ K6 declared budget: **≤ 2** (per §10). K6-A1 actual at close: **0** refutations. Two §20.5 amendments folded inline (16.1 spec clarification, 16.2 toolchain adaptations); per §20.9 classification rules these do not consume the refutation budget. Both were anticipated at the opener — the cpio shape choice was named "JS-built variant deferred to K6-B1" in §7 of the opener doc; the toolchain-assembler-syntax surface is the same class as the K5 ``,"",@``-pattern already in use across arch/wasm32's .S files. Trajectory holds favorable (≤ 1 refutation projected for K6-B1+). 16.4 K6-A2 amendment (§20.5 source-name drift) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ K6-A2's source-site snapshot revealed one upstream-name drift against §6: * §6 names the execve entry as ``do_execve_common``; upstream v6.12 spells it ``do_execveat_common`` (with the extra ``at``). The opener doc was drafted from memory of older Linux versions where the symbol was simpler; the snapshot pins the actual upstream name as of K6's pinned tag. Classified §20.5 (not refutation): the spec's *intent* — "the execve entry point that bprm_execve flows into" — is preserved; only the symbol name needed correction. The snapshot file (``rootfs-model-source-snapshots.txt``) carries an inline ``[NOTE]`` capturing the drift; this section is the spec-side acknowledgement. The next time §6 is refreshed (e.g. an upstream tag bump) it should pick up the canonical name. K6-A2 also formalised the §6 enumeration as an executable artifact rather than a four-rg-command checklist: :: $ bash linux-wasm/tools/k6-rootfs-model-probe/snapshot-sources.sh regenerates ``Documentation/wasm/rootfs-model-source-snapshots.txt`` byte-deterministically (sorted, date-only timestamp). The script is K6-B's source of truth for upstream surface — any K6-B patch hunk whose line numbers don't match the snapshot is either spec drift (re-run + commit) or stale (re-read the surrounding code). 16.5 K6-A2 close — refutation count vs budget ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ K6 declared budget: **≤ 2** (per §10). K6-A2 actual at close: **0** refutations (cumulative K6: **0**). One §20.5 source-name drift folded inline (16.4); per §20.9 classification rules this does not consume the refutation budget. Trajectory holds favorable (≤ 1 refutation projected for K6-B1+). 16.6 K6-B1 amendments (§20.5 spec/struct drift + §15 row surfaced) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Three §20.5 amendments landed at K6-B1, all folded inline: (a) **Opener struct mental-model vs. real struct.** The K6 opener's §15 listed a 7-field, 56-byte struct with magic ``0xB007B007`` as the v1 baseline. The actual v1 struct (live in ``arch/wasm32/include/asm/boot.h`` since K2) has 15+ fields, is 96 bytes, and uses magic ``0x31494257`` ('WBI1'). The opener's struct was an exposition sketch, not a citation of the real surface. §15 has been rewritten to reflect the real layout; the rewrite cites the C header as the single source of truth. Classified §20.5 (spec mental-model correction, not contract refutation). (b) **v2 forward-compat path deferred.** The opener said v2 kernels would accept v1 callers (zero-init initrd_start/end and fall through to the K5-C2 fallback). K6-B1 instead implements strict ``abi_version == 2`` match-or-panic, matching the K5 strict pattern. Both sides are bumped in lockstep so there is no current caller that needs the v1-compat slack. The choice is reversible (a future K-phase could add an explicit ``if (version == 1) goto no_initrd`` branch); we noted the divergence here so the opener's intent is on the record. Classified §20.5 (scope contraction documented at close, not at open). (c) **wasm32 initcall dispatch is broken — §15 row, K6-B1 workaround.** During K6-B1 implementation, T4' surfaced that the upstream ``rootfs_initcall(populate_rootfs)`` never runs on wasm32: ``__initcall*_start/_end`` are 0-imports (see ``arch/wasm32/kernel/sections.c``), so ``initcall_levels[]`` is all-NULL and ``do_initcalls`` is an empty loop. K6-B1's workaround is to call ``unpack_to_rootfs`` directly from ``arch_kernel_init_pre_run_init`` — a single arch-side site that bridges populate_rootfs without invoking the missing dispatch infrastructure. This is sufficient for K6 acceptance; a generic initcall-dispatch shim is filed as a future §15 row to be picked up when subsystem initcalls beyond populate_rootfs become load-bearing. Classified §20.5 (newly-discovered §15 row, not contract refutation): the wasm32 port's "initcalls don't run" reality has been consistent since K2; K6-B1 is the first sub-phase to need a specific initcall to fire, so it surfaces now. K6-B1 patches: * **No new upstream patch files added.** The K6-B1 changes are arch-side only (``arch/wasm32/include/asm/boot.h``, ``arch/wasm32/kernel/setup.c``, ``arch/wasm32/kernel/init.c``, ``arch/wasm32/kernel/k6_b1_probes.c`` new). The ``unpack_to_rootfs`` symbol is exposed via the existing ``patches/0006-init-expose-unpack_to_rootfs-for-arch-probes`` landed at K6-A1. * **TypeScript ABI mirror** (``hardwarejs/src/boot-info-abi.ts``, new) exports the v2 constants and a ``writeBootInfoV2`` helper. * **TypeScript test** (``hardwarejs/test/k6-b1-bootinfo-v2.test.ts``, new) covers three sub-tests: no-initramfs regression (K5-C2 continues to dispatch), with-initramfs T4' end-to-end (JS-built cpio reaches rootfs and is found via ``kern_path``), and a pure-TS sanity check on the mirror constants vs the C side. * **K2 boot-info test updated** (``hardwarejs/test/k2-bootinfo.test.ts``) to construct v2 boot_info in its negative-path expectTrapWith helpers; the ``reserved[2]`` test became ``reserved[1]`` because v2's reserved is u32[2]. 16.7 K6-B1 close — refutation count vs budget ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ K6 declared budget: **≤ 2** (per §10). K6-B1 actual at close: **0** refutations (cumulative K6: **0**). Three §20.5 amendments folded inline at 16.6 (struct mental- model correction, v2 forward-compat deferral, wasm32-initcall §15 row); per §20.9 classification rules these do not consume the refutation budget. The wasm32-initcall §15 row is the first "newly-discovered upstream-surface row" in K6, and it lands as a localised K6-B1-scoped workaround rather than a generic fix — matching the deferral pattern §8 of this document anticipates. Trajectory holds favorable (≤ 1 refutation projected for K6-B2..K6-D). 16.8 K6-B2 close — refutation count vs budget ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ K6 declared budget: **≤ 2** (per §10). K6-B2 actual at close: **0** refutations (cumulative K6: **0**). K6-B2 surface: one new patch (``patches/0005-fs-add-arch_post_execve-hook.patch``) adds a weak ``arch_post_execve(struct linux_binprm *bprm)`` to upstream ``fs/exec.c``'s ``bprm_execve`` success path, after the standard post-execve teardown (``sched_mm_cid_after_execve``, ``in_execve`` clearance, ``rseq_execve``, ``user_events_execve``, ``acct_update_integrals``, ``task_numa_free``). The weak default is a no-op; the strong override lands at K6-B5 (``arch/wasm32/kernel/init.c``). Why ``bprm_execve`` (not ``do_execveat_common``): the hook must observe ``bprm->binfmt`` (so arch overrides can discriminate "this was binfmt_wasm vs. ELF / script / etc.") AND must observe the task in its fully-committed post-execve state. ``bprm_execve`` owns both — ``exec_binprm()`` has just returned with ``bprm->binfmt`` set, and the standard post-execve hooks have just finished. ``do_execveat_common`` would be too early (teardown not yet run); after ``do_execveat_common`` returns is too late (bprm has been freed). See patches/0005 header for the full rationale. Why pass full ``struct linux_binprm *`` (not just ``struct linux_binfmt *``): future arch overrides may want to inspect ``bprm->file``, ``bprm->cred``, etc. — passing the bprm keeps room without locking the ABI. The K6-B5 override only needs ``bprm->binfmt``, but K7+ overrides are not constrained. The K6-B2 vitest is shaped to ALSO pass against the K6-B5 strong override (it passes ``struct linux_binprm dummy = { 0 }`` so ``dummy.binfmt == &wasm_format`` evaluates false and the override's parking branch skips). The probe therefore stays valid as a regression check across K6-B2 → K6-B5. No §20.5 amendments. No new §15 rows surfaced. The patch is the smallest possible touch of an upstream core file and applies via ``git apply`` cleanly. Trajectory holds favorable (≤ 1 refutation projected for K6-B3..K6-D). 16.9 K6-B3 close — sub-phase scope fold (§20.5 amendment) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ K6 declared budget: **≤ 2** (per §10). K6-B3 actual at close: **0** refutations (cumulative K6: **0**). **K6-B3's described surface landed at K6-B1.** Per §13: (B3) ``arch/wasm32/kernel/setup.c`` reads ``boot_info.initrd_offset`` / ``initrd_size``, sets up ``initrd_start`` / ``initrd_end`` global symbols (their address is what ``init/initramfs.c::populate_rootfs`` reads). Audited at K6-B3 opener time — every named element is present in ``arch/wasm32/kernel/setup.c`` since commit ``c690632``: * Reads of ``bi->initrd_offset`` / ``bi->initrd_size`` — ``wasm_validate_boot_info`` lines 115-116 and ``setup_arch`` lines 280-281 (Step 7d header at line 420). * Sets of ``initrd_start`` / ``initrd_end`` — lines 442-443. * Plus surface K6-B3's §13 description doesn't enumerate but which is part of the complete substrate: four validation rejections (one-zero-one-not, extends-past-total, before-kernel-image-end, overlaps-memblock) at lines 192-209, and ``initrd_below_start_ok = 1`` at line 458 (necessary because the wasm32 initrd lives in the prologue below ``min_low_pfn``; upstream's ``page_to_pfn(virt_to_page( initrd_start)) >= min_low_pfn`` check would otherwise discard the initrd with "initrd overwritten - disabling it."). **Why folded into K6-B1 instead of landed separately.** The two surfaces are inseparable in any acceptance shape: 1. K6-B1 bumps the ABI from v1 to v2 by adding ``initrd_offset`` / ``initrd_size`` to ``struct wasm_boot_info``. v2 is asserted via ``static_assert`` on the C side and v1-rejecting validation in the JS-side test suite. Either both fields exist and have a consumer, or the ABI is half-cooked (kernel accepts v2 but does nothing with the new fields → undetectable spec drift, exactly what §20.6 source-site enumeration is meant to prevent). 2. K6-B1's T4' end-to-end vitest (``hardwarejs/test/k6-b1-bootinfo-v2.test.ts`` sub-test B) asserts the full chain HardwareJS → boot_info v2 → setup_arch → ``initrd_start/end`` → unpacked-rootfs → marker file resolvable via ``kern_path()``. That chain only closes if ``setup.c`` actually reads the v2 fields and publishes the globals — i.e. K6-B3's surface. Splitting K6-B3 into a later commit would have left K6-B1 unable to make its T4' claim. The §13 sub-phase split therefore reflected the intended sequencing as an exposition (boot ABI first, then setup.c consumer), not as a commit boundary. K6-B1's commit ``c690632`` body explicitly cites the ``setup.c`` changes — the trail is auditable. **Sub-phase trail correctness.** Per K6 opener's standing-note discipline (single-axis, commit-per-sub-phase even when surface was empty), K6-B3 closes here as a docs-only commit so the K-phase sequence stays auditable. The next sub-phase is K6-B4 (real ``binfmt_wasm.load_wasm_binary`` loader) and proceeds unchanged. No §15 rows surfaced. No refutations. Trajectory holds favorable (≤ 1 refutation projected for K6-B4..K6-D). 16.10 K6-B4 close — real binfmt_wasm loader (§15 row resolved + §20.5 source-name drift) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ K6 declared budget: **≤ 2** (per §10). K6-B4 actual at close: **1** refutation surfaced and resolved inline (cumulative K6: **1**, vs budget ≤ 2 — within budget). **Surface landed.** ``arch/wasm32/kernel/binfmt_wasm.c::load_wasm_binary`` becomes a real loader: * Magic + version match → ``kmalloc(i_size, GFP_KERNEL)`` a buffer in env.kernel_memory (identity-mapped per memory- model.rst §1; vmalloc's VMALLOC_START range 0xd0000000+ is NOT in env.kernel_memory and cannot be passed to HardwareJS via the spawn-ring exec_image pointer). * ``kernel_read(file, buf, size, &pos)`` for the full payload. (See "§20.5 source-name drift (1)" below for why ``kernel_read``, not ``kernel_read_file``.) * ``begin_new_exec(bprm)`` — point of no return; transitions the task to the new exec image and commits creds. The K6 opener §13 mentioned ``install_exec_creds`` as a separate step; that call was deprecated upstream and merged into ``begin_new_exec`` for kernel ≥ 6.x. (See "§20.5 source-name drift (2)" below.) * ``setup_new_exec(bprm)``. * ``set_binfmt(&wasm_format)`` so K6-B5's arch_post_execve override can discriminate via ``current->mm->binfmt``. (See "§20.5 source-name drift (3)" below.) * ``wasm32_exec_image(buf, size, filename)`` — submits the spawn-ring FORK request (existing K5-C2 entry point). * ``finalize_exec(bprm)``. * ``kfree(buf)`` (spawn-ring is synchronous — HardwareJS has consumed the bytes by the time host_spawn_process_worker returns). * Return 0. K5's match-but-return-ENOEXEC stub is removed; pre-PNR failures (bad i_size, kernel_read errors) now return real errnos like ``-EIO`` / ``-EINVAL`` so the binfmt walker does NOT fall through to ``binfmt_script`` on a magic-matched but malformed WASM file. **§15 row surfaced and resolved.** First end-to-end run of the probe failed with ``kernel_execve`` returning ``-ENOMEM`` silently. Root cause: ``arch/wasm32/mm/pgtable.c::pgd_alloc`` was a K0-era stub returning ``NULL``, which made ``mm_init → mm_alloc_pgd`` fail, which made ``bprm_mm_init → mm_alloc`` return ``NULL``, which made ``alloc_bprm`` propagate ``-ENOMEM``. This is a single refutation in the §20.9 sense: the K6 opener §13 (B4) didn't enumerate the mm-allocation prerequisite at source-site granularity. Captured under §15 row "mm subsystem incomplete (pgd_alloc stub)" and resolved in the same commit by upgrading ``pgd_alloc`` to allocate a real ``__get_free_page(GFP_KERNEL | __GFP_ZERO)`` placeholder. The wasm engine handles all real address translation against memory 0 (identity-mapped); the PGD page exists only for upstream's mm bookkeeping (mm->pgd pointer dereferences in free_pgtables, ptdump, etc.). Per-mm cost: one 4 KiB page, acceptable at K6 mm-churn levels. A regression guard mm_alloc check sits at the top of the K6-B4 probe so any future regression of ``pgd_alloc`` is caught at the probe-entry boundary with a clear "mm_init/ pgd_alloc regression" dmesg line rather than silent -ENOMEM downstream. **§20.5 source-name drift (1) — ``kernel_read`` vs ``kernel_read_file``.** The K6 opener §13 specified ``kernel_read_file``; investigation found that ``kernel_read_file`` does ``deny_write_access(file)`` which fails ``-ETXTBSY`` if the file has any pending writer or has not had its deferred ``fput()`` task-work run since the last write. The initramfs unpacker's ``fput()`` on the just-written ``/init`` is deferred (task-work), so it has not run by the time the next probe-iteration's kernel_execve opens /init for exec. ``kernel_read`` is the lower-level path that binfmt_elf itself uses (see ``elf_read``); it does not deny_write_access. ``bprm->file`` already has ``FMODE_EXEC + deny-writes`` applied via ``do_open_execat`` so the redundant guard adds no value at this call site. **§20.5 source-name drift (2) — ``install_exec_creds`` removed.** The K6 opener §13 (B4) named ``install_exec_creds`` as a separate step after ``setup_new_exec``. That call was deprecated and removed upstream in 5.10 (commit ``b8a61c9e7b4a``); creds are committed inside ``begin_new_exec`` via ``commit_creds(bprm->cred)``. K6-B4 follows the canonical 6.x ``binfmt_elf`` shape: ``begin_new_exec → setup_new_exec → set_binfmt → ... → finalize_exec → return 0``. **§20.5 source-name drift (3) — discriminator field name.** The K6 opener referenced ``bprm->binfmt`` for the K6-B5 override's discriminator; ``struct linux_binprm`` has no such field. The matched binfmt is stored canonically in ``current->mm->binfmt`` via ``set_binfmt()`` (see ``fs/exec.c`` line 1455). ``load_wasm_binary`` now calls ``set_binfmt(&wasm_format)`` after ``begin_new_exec`` so K6-B5 can discriminate via ``current->mm->binfmt`` (exposed as the file-local helper ``wasm32_current_is_wasm_binfmt()`` in ``binfmt_wasm.c``). **Additional surface needed beyond §13's enumeration.** * ``arch/wasm32/kernel/process.c::flush_thread`` — added as no-op stub (begin_new_exec calls it; wasm32 has no user- mode arch state to flush across exec because user state lives in the separate Worker, freshly spawned each execve). **Probe shape.** ``arch/wasm32/kernel/k6_b4_probes.c`` dispatched on cmdline ``k6_b4_probes=1``. Runs ``mm_alloc`` sanity (regression guard for the §15 row) → ``kern_path(/init)`` → ``kernel_execve("/init", argv, envp)`` → logs return value. JS-side vitest (``hardwarejs/test/k6-b4-binfmt-wasm-loader.test.ts``) builds a newc cpio containing ``/init`` = ``wackywasm-tools/build/ hello-k5.wasm``, boots vmlinux with cmdline ``k6_b4_probes=1``, and asserts the full chain reaches "hello from K5 userspace" on the user-Worker stdout while the kernel-side dmesg shows the load_complete + kernel_execve_returned_0 markers. **Trajectory.** Cumulative K6: 1 refutation surfaced and resolved (§15 row), all inline. Remaining sub-phases (K6-B5, K6-C, K6-D) project ≤ 1 additional refutation; total budget ≤ 2 holds with 1-row margin. 16.11 K6-B5 close — arch_post_execve strong override + test-fold ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ K6 declared budget: **≤ 2** (per §10). K6-B5 actual at close: **0** refutations (cumulative K6: **1**). **Surface landed.** ``arch/wasm32/kernel/init.c`` defines ``arch_post_execve(struct linux_binprm *bprm)`` as a strong override of the K6-B2 weak default. The body: .. code-block:: c void arch_post_execve(struct linux_binprm *bprm) { (void)bprm; if (!wasm32_current_is_wasm_binfmt()) return; pr_info("wasm32: arch_post_execve parking kthread " "for pid=%d ...\n", current->pid); park_kthread_forever(); } Discriminator is ``current->mm->binfmt == &wasm_format`` (via the file-local ``wasm32_current_is_wasm_binfmt`` helper added at K6-B4). When the just-completed execve matched binfmt_wasm, the kernel-side task is parked forever — schedule() in TASK_UNINTERRUPTIBLE never returns it. Same parking shape as K5-C2's post-spawn dispatcher; this hook moves the parking from the embedded-image entry point into the canonical post-execve site so the K6-C end-to-end path (real /init via kernel_init → run_init_process → bprm_execve → load_wasm_binary → arch_post_execve) parks correctly without arch-specific bookkeeping outside fs/exec.c's normal flow. For non-wasm execves (e.g. the K6-B2 probe's dummy bprm with binfmt=NULL), the discriminator returns false and arch_post_execve is a no-op — preserving the K6-B2 weak-default contract under the strong override. **Test fold.** K6-B5 does NOT add a new vitest file. Its surface is covered by: * ``hardwarejs/test/k6-b4-binfmt-wasm-loader.test.ts`` — updated to assert the strong override's parking dmesg ``wasm32: arch_post_execve parking kthread for pid=...`` appears, AND the regression-marker ``K6-B4-PROBE: kernel_execve returned 0`` does NOT appear (would mean arch_post_execve regressed to the weak default). * ``hardwarejs/test/k6-b2-arch-post-execve.test.ts`` sub-test A — verifies the no-op branch for non-wasm bprm; passes unchanged under K6-B5 because dummy.binfmt=NULL ⇒ current->mm->binfmt also NULL ⇒ discriminator false ⇒ arch_post_execve no-op. * K6-B2 sub-test B — K5-C2 builtin-init regression; passes unchanged. A dedicated ``k6-b5-arch-post-execve-strong.test.ts`` would duplicate the K6-B4 assertions verbatim and the K6-B2 sub-test A's discriminator coverage. Same shape as the K6-B3 sub-phase scope fold (§16.9), except K6-B5's C surface is non-empty: the strong override is genuinely new code; it's only the test that folds. This is documented inline so the K-phase audit trail shows "K6-B5 had a separate C deliverable AND no separate vitest" without needing an external commit-body cross-reference. **Trajectory.** Cumulative K6: 1 refutation total (K6-B4's §15 row), well within the ≤ 2 budget. K6-C / K6-D project 0 refutations each. K6 close projection unchanged. 16.12 K6-C1 close — build-k6-initramfs.sh ships ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ K6 declared budget: **≤ 2** (per §10). K6-C1 actual at close: **0** refutations (cumulative K6: **1**). **Surface landed.** ``linux-wasm/scripts/build-k6-initramfs.sh`` emits a newc cpio archive containing one regular file ``/init`` with content read from ``wackywasm-tools/build/ hello-k5.wasm`` (or an empty TRAILER-only archive if the hello-k5.wasm is missing, for clean-checkout / K6-C3 fallback exercising). Implemented as a thin bash wrapper around an inline ``python3`` heredoc that does the newc framing (110-byte ASCII header per entry, NUL-padded to 4 bytes). Determinism is load-bearing: * mtime = 0 (epoch) instead of ``time(NULL)``. * uid = gid = 0. * nlink = 1. * devmajor/minor and rdevmajor/minor = 0. * check field = 0 (newc specifies this). * Inode numbers assigned 1, 2, ... in entry order (deterministic iteration). Verified: two runs of the script against the same input bytes produce byte-identical output (matching SHA256). K6-C2 vitest treats this as a regression marker. **Makefile target.** ``make -C linux-wasm k6-initramfs`` invokes the script with ``BUILTIN_INIT_WASM`` (already used by the K5-C2 ``builtin-init-image`` target) and writes to ``linux-wasm/build/k6-initramfs.cpio``. The K6-C2 vitest's ``beforeAll`` also invokes the script directly so test runs always exercise the canonical script path (no stale .cpio from a previous test session). **No refutations.** The opener's description ("byte-deterministic so vitest can snapshot-test it") landed as specified. 16.13 K6-C2 close — end-to-end fs-init via kernel_execve in arch hook ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ K6 declared budget: **≤ 2** (per §10). K6-C2 actual at close: **1** refutation surfaced and resolved inline (cumulative K6: **2** — at the budget cap). **Surface landed.** ``arch_kernel_init_pre_run_init`` in ``arch/wasm32/kernel/init.c`` now: 1. Unpacks the boot_info v2 initramfs (already from K6-B1). 2. Probe-boot dispatches (k6_a1, k6_b1, k6_b2, k6_b4) opt-in on cmdline, park, never return. 3. **K6-C2 branch**: ``kern_path("/init", LOOKUP_FOLLOW, &p)`` to test whether /init exists in the rootfs: * Present → ``kernel_execve("/init", argv, envp)`` directly. With K6-B4 + K6-B5 landed, this exercises the full binfmt walker chain (alloc_bprm → prepare_binprm → bprm_execve → search_binary_handler → load_wasm_binary → wasm32_exec_image spawn-ring → arch_post_execve parks current; kernel_execve never returns). * Absent → fall through to K5-C2 builtin-image dispatch (the K6-C3 fallback contract). **Refutation #2 of ≤ 2 surfaced and resolved.** The K6 opener §13 (C2) described the fs path as flowing through "kernel_init → run_init_process("/init") → bprm_execve → load_wasm_binary". That path requires upstream's ``kernel_init_freeable`` to NOT have already reset ``ramdisk_execute_command`` to NULL before ``arch_kernel_init_pre_run_init`` runs. On wasm32 the order is: 1. ``kernel_init_freeable()`` runs first; it calls ``init_eaccess("/init")``. Because wasm32 doesn't dispatch initcalls (§15 row, see ``sections.c``), populate_rootfs hasn't run yet → ``/init`` doesn't exist → init_eaccess fails → ``ramdisk_execute_command = NULL``. 2. ``arch_kernel_init_pre_run_init()`` then runs and unpacks the rootfs. Too late — kernel_init's downstream ``if (ramdisk_execute_command)`` branch is dead. 3. kernel_init iterates ``/sbin/init``, ``/etc/init``, ``/bin/init``, ``/bin/sh`` (none exist) and panics with "No working init found". The §15 "wasm32 doesn't dispatch initcalls" row therefore strikes twice in K6: * K6-B1: ``populate_rootfs`` itself doesn't fire as a rootfs_initcall (bridged by ``wasm32_populate_rootfs_initrd`` in arch_kernel_init_pre_run_init). * K6-C2: the upstream caller already gave up on ``ramdisk_execute_command`` by the time we unpacked. Both bridged by arch_kernel_init_pre_run_init taking the relevant action directly. K6-C2's bridge is to call ``kernel_execve("/init", argv, envp)`` from the arch hook once /init is confirmed present in the rootfs. This still exercises the full do_execve chain (binfmt walker, real load_wasm_binary, arch_post_execve) — the only "missing" upstream surface is the **caller** of kernel_execve being ``kernel_init`` itself vs ``arch_kernel_init_pre_run_init``. From the binfmt-walker's perspective the two are identical (both run in kernel_init's task context with non-PF_KTHREAD flags). The acceptance gate (§4 R3: kernel_init reaches run_init_process equivalent for /init) is met functionally even though the upstream-text-canonical "Run /init as init process" pr_info line does not appear. A unified fix (real initcall dispatch on wasm32) would resolve both §15 rows and let kernel_init run /init via its normal ``if (ramdisk_execute_command)`` branch. Tracked as a K8+ item; K6 ships with the arch-hook bridge. **Test.** ``hardwarejs/test/k6-c2-fs-init.test.ts`` boots vmlinux with the K6-C1-built cpio (rebuilt in ``beforeAll`` so the test always exercises the canonical script path) and NO probe cmdline. Asserts: * ``wasm32: /init present in rootfs; invoking kernel_execve(/init) directly`` — fs-init engaged via arch hook. * ``binfmt_wasm: loading /init (K6-B4 real loader)`` — real loader fired. * ``binfmt_wasm: load complete for /init`` — loader returned 0. * ``wasm32: arch_post_execve parking kthread for pid=`` — K6-B5 parking fired. * User-Worker stdout contains ``hello from K5 userspace``. * K5-C2 fallback markers (``dispatching to builtin init image``, ``Kernel panic``, ``No working init``) do NOT appear. **Trajectory.** Cumulative K6: 2 refutations (budget cap). Remaining sub-phases (K6-C3, K6-D) project 0 additional refutations — fallback test is structural and K6-D is docs-only. 16.14 K6-C3 close — empty-initramfs fallback to K5-C2 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ K6 declared budget: **≤ 2** (per §10). K6-C3 actual at close: **0** refutations (cumulative K6: **2**). **Surface landed.** No new C surface. K6-C3 is a structural regression test that pins: * ``wasm32_populate_rootfs_initrd`` correctly handles a TRAILER-only newc cpio (parses, creates no files, reports unpack ok). The cpio is built inline in the JS-side test (``buildEmptyNewcCpio()``) — same format as ``build-k6-initramfs.sh`` emits when hello-k5.wasm is missing. * The K6-C2 ``kern_path("/init")`` branch's "absent" arm correctly falls through to the K5-C2 builtin dispatch instead of e.g. always taking the fs path and panicking. * K5-C2 builtin dispatch still works end-to-end (hello-k5 stdout reaches the user-Worker output callback) after all the K6-A..C surface accumulation. **Test shape.** ``hardwarejs/test/k6-c3-fs-fallback.test.ts`` asserts the positive dmesg path: * ``wasm32: Unpacking initramfs from`` — empty cpio unpacked. * ``wasm32: initramfs unpack ok`` — no parse errors on TRAILER. * ``wasm32: /init not in rootfs (kern_path=-2)`` — fallback message; -2 = -ENOENT confirms the kern_path failure mode. * ``wasm32: dispatching to builtin init image`` — K5-C2 path. * User-Worker stdout contains ``hello from K5 userspace``. And negative assertions: * K6-C2 fs-path message ``wasm32: /init present in rootfs`` does NOT appear. * No oops/BUG/panic. §4 R4 closes. **Why the TRAILER-only cpio is built inline rather than via build-k6-initramfs.sh.** Vitest worker sandboxes vary in PATH and python3 availability across hosts; embedding the buildEmptyNewcCpio helper in TS keeps the test self-contained. The format is documented in the K6-C1 script's heredoc, and the K6-C1 commit verifies the script produces the same shape when run directly. Future K-phases could extract a shared helper if duplication grows further (already 3 newc-cpio emitters across the JS side: K6-B1, K6-B4, K6-C3); K6-D1's audit will surface or defer that refactor. **Trajectory.** Cumulative K6: 2 refutations (budget cap, no change from K6-C2). K6-D projects 0 additional refutations — audit and Appendix A refresh are docs-only. 16.15 K6-D1 audit — R1-R7 → test-file mapping ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Per §13 K6-D1, every R-row from §9 has at least one sub-test under ``hardwarejs/test/k6-*``. Mapping: ============ ===================================================== ==================================================== R-row Test file Sub-test / assertion ============ ===================================================== ==================================================== R1 ``k6-b1-bootinfo-v2.test.ts`` Sub-test B (T4'): JS-built cpio → boot_info v2 → setup_arch → unpack → ``kern_path("/k6-b1-test-marker")`` succeeds. R2 ``k6-b4-binfmt-wasm-loader.test.ts`` "binfmt_wasm: read N bytes from /init"; "load complete for /init". R3 ``k6-c2-fs-init.test.ts`` "wasm32: /init present in rootfs; invoking kernel_execve(/init) directly"; "binfmt_wasm: load complete"; user-Worker stdout contains "hello from K5 userspace". Caller is the arch hook rather than upstream kernel_init due to the §15 row §16.13; the do_execve flow itself is upstream-canonical. R4 ``k6-c3-fs-fallback.test.ts`` Empty TRAILER-only cpio → kern_path(/init)=-ENOENT → K5-C2 dispatch → "hello from K5 userspace" still surfaces. R5 K6-C1 commit + ``k6-c2-fs-init.test.ts`` beforeAll Script ships at ``linux-wasm/scripts/build-k6-initramfs.sh``; K6-C2 test's beforeAll regenerates the cpio so the deterministic-output property is exercised every run. R6 ``k6-bootkernel-spawn-defaults.test.ts`` Three-mode handler-resolution matrix; pre-K6 implementation regression-pin landed at K6 opener. K6 acceptance retains this test in ``make hwjs-verify``. R7.a ``k6-b2-arch-post-execve.test.ts`` sub-test A Dummy bprm with binfmt=NULL → arch_post_execve callable + no-op confirmed. R7.b ``k6-b4-binfmt-wasm-loader.test.ts`` + K6-B4 asserts the parking dmesg "wasm32: ``k6-c2-fs-init.test.ts`` arch_post_execve parking kthread for pid="; K6-C2 also asserts it through the natural fs-init path. ============ ===================================================== ==================================================== Additional K6 substrate tests (not §9 R-rows but landed during implementation and exercised by ``hwjs-verify``): * ``k6-a1-rootfs-probes.test.ts`` — T4 cpio-unpack + T5 kmalloc-readback substrate probes (K6-A1 acceptance). * ``k6-b1-bootinfo-v2.test.ts`` sub-tests A, C — no-initramfs regression and boot-info-abi-constants pin. * ``k6-b2-arch-post-execve.test.ts`` sub-test B — K5-C2 builtin-init regression under patches/0005. No R-row is unrecited. No §20.6 discipline violations. 16.16 K6 close — cumulative ledger ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Refutation budget vs actual.** ================ ============================== =========================================== Sub-phase Refutations Notes ================ ============================== =========================================== K6 opener 0 §10 budget set to ≤ 2. K6-A1 0 (after §20.5 amendment) Spec drift on T4 wording surfaced and folded inline; not counted per §20.5 discipline. K6-A2 0 Source-site enumeration landed clean. K6-B1 0 (3 §20.5 amendments) Spec/struct drift documented inline: ABI-v2 mental model, forward-compat deferral, initcall-bridge §15 row surfaced. K6-B2 0 Weak default landed clean. K6-B3 0 Sub-phase scope-fold (§20.5 amendment); substrate landed at K6-B1. K6-B4 **1** §15 row surfaced and resolved inline: pgd_alloc was a K0-era stub returning NULL. Upgraded to real ``__get_free_page``. Plus 3 §20.5 source-name drifts (kernel_read vs kernel_read_file; install_exec_creds removed; current->mm->binfmt vs bprm->binfmt). K6-B5 0 Strong override + test-fold (no new vitest file; coverage via K6-B4 + K6-B2). K6-C1 0 build-k6-initramfs.sh ships. K6-C2 **1** §15 row strikes again: wasm32 no-initcall-dispatch row clobbers ``ramdisk_execute_command`` pre-arch-hook; bridged by calling kernel_execve from arch_kernel_init_pre_run_init directly. K6-C3 0 Empty-initramfs fallback structural test. K6-D1 0 Audit clean. **Cumulative** **2** At the ≤ 2 budget cap; within budget. ================ ============================== =========================================== **Calibration for K7.** The K6 close at 2 refutations vs ≤ 2 budget is exactly at the cap. Two takeaways for K7 opener-budget setting: 1. Both K6 refutations stemmed from the same §15 row (wasm32 doesn't dispatch initcalls). A K8+ unified fix (real initcall dispatch on wasm32) would resolve the underlying row and pre-empt this class of refutation. K7 opener may want to budget headroom for "underlying §15 rows surface in new surface areas". 2. The §20.5 source-name drift count was higher than usual (K6 total: 5+ amendments across opener mental model, B4 source-names, B1 ABI mental model). This is because K6 touched a lot of relatively unfamiliar upstream surface (binfmt walker, mm init, exec credentials, namespaces). K7 = U-series rebuilds the same /init binary against real musl on K6's path; the upstream surface K7 touches is already well-explored at K6 close, so §20.5 drift should be lower at K7. K7 budget proposal: **≤ 1** refutation, per the §20.9 three-input formula (K6 actual 2, decreasing surface novelty, single-axis discipline holding). **Test suite at K6 close.** 19 test files pass under ``make hwjs-verify``: * K0..K5 regression suite (k0-* through k5-c2-builtin-init). * K6-A1, K6-B1, K6-B2, K6-B4, K6-C2, K6-C3. * K6-bootkernel-spawn-defaults (opener amendment). 58 tests pass; 2 skipped (unrelated to K6 surface). All gates (R1-R7, §12.α/β/γ) closed. **K6 acceptance achieved.** "First fs-loaded execve" per §2 Option C: an /init.wasm file in a HardwareJS-supplied initramfs runs successfully via the do_execve binfmt walker. The K7 U-series can now swap the libwacky-built hello-k5 for a real-musl rebuild on this exact path.