sk_v4_mint_zuse wiped seed and rseed only when the real Zuse was minted; its
refusals and every failure after YES left them in stack memory.
Option 1 (Captain Bob, 2026-11-12: "1 is great"): the seeds are in a 64-byte
buffer the caller owns. sk_v4_mint_zuse_with(seeds) runs the mint (now a
private mint()) and then wipes the buffer, whichever way it returned -- one
place, every exit; sk_v4_mint_zuse() gives it a buffer of its own.
kernel/tests/test_sk_v4_mint.c, 17 checks: the real gpt.c on the RAM disk, the
identity code, key mint, signature checks, marker and keyboard faked; each of
the mint's eight exits run with the buffer filled with 0xEE first -- no stick,
under 64 MiB, not YES, the key mint failing, the read-back not hers, no
marker, the marker write failing, and minted. Against the mint as it was: 7
failures (every exit but success). Now: 0. Both runs in logs/20261112-181719/. Built for
amd64, aarch64, riscv64. The identity code's two (sk_v4_genesis,
sk_v4_real_zuse_arrived) follow.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
sk_v4_grow.c's dev_rw4k computes 1 KiB block numbers as (uint32_t)devblock * 4,
which wraps past 4 TiB; Artemis is capped at 256 GiB (STICK_ARTEMIS_CAP_GIB,
kernel/Makefile), so it is latent -- but nothing said so where the cast is. Now
a compile-time check there (the C99 negative-array pattern the tree uses): a
cap past 4 TiB stops the build, and a cap not defined at all is an #error, not
a skipped check. gpt.c's casts are bounded by the disk's own size, itself a
32-bit count of 1 KiB blocks, checked before each: each now says so.
kernel/tests' check_cap, seen to fail first (a 4096 GiB cap built); now 3
checks, 0 failures -- 256 GiB builds, 4096 GiB and none refused. Built for
amd64, aarch64, riscv64. The plan's increments 2 and 3 marked.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
sk_v4_idle allocated a controller's slot array again whenever max_slots + 1
was more than it held -- the old array dropped, neither copied nor freed --
while the identity code holds pointers into it (g_offered, g_spare,
g_pending_real, g_real_drive, g_zuse_dev). Its two slot loops then ran to
max_slots whatever the array held.
sk_v4_slots_get() (kernel/src/v4/sk_v4_slots.c): allocated once, zeroed, at the
size first asked for; never replaced; the slots that may be used are those it
has. sk_v4_idle uses it, and its loops stop at the array's end.
kernel/tests/test_sk_v4_slots.c, kmalloc_aligned faked, seen to fail first
against the allocation as it was (4 failures: replaced when more were asked
for, 17 said usable where 9 existed, a held pointer left behind, an allocation
for 0); now 6 checks, 0 failures. Built for amd64, aarch64, riscv64; latent
today (max_slots does not grow), so the boots show no change.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
sk_v4_run's three stops -- "not started", "did not let go of POST's
blocks", "stopped on a fault" -- ended in for (;;) { }: a core spinning at
100%, the thing #151 removed from the prompt. Each now calls sk_v4_stop()
(kernel/src/v4/sk_v4_stop.c): interrupts off, then arch_halt() for ever. Each
still says why first. sk_v4_stop.c added to the loader's and the kernel's v4
sources.
kernel/tests/test_sk_v4_stop.c, with arch_halt and arch_disable_interrupts
faked (the halt jumps back out after three calls; an alarm fails a spin):
against the stop as it was -- "spun for 2 s without halting"; now -- 2
checks, 0 failures: halts in a loop, interrupts off before the first halt.
Built for amd64, aarch64 and riscv64. #177's "seen on the three
architectures": no boot reaches these stops, so it is shown on the host only.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
xhci.c's XHCI_XFER_CONFIG_DESC_FULL case walked the descriptor set inline, in
the event loop, where nothing could test it. The walk is now
usb_config_parse() (kernel/src/usb/usb_config.c), returning what it found;
the case acts on it as before -- the same messages, the same decisions: the
first Interface descriptor only, a BOT interface's bulk endpoints (the last of
each direction), a boot keyboard's first interrupt IN endpoint, bLength 0
ending the walk, nothing read past len. One difference, in debug output only:
the bulk endpoints are logged IN then OUT, not in descriptor order.
kernel/tests/test_usb_config.c, 7 checks, pins the walk as moved: a BOT stick
as QEMU presents it, a boot keyboard with its HID descriptor, a mouse before a
drive (the first interface only), a drive with bulk IN only, bLength 0, an
endpoint cut by len, an interface cut before its protocol byte. All pass.
Built for amd64, aarch64, riscv64; the boots come with the protocol (a data
stick enumerates through this path). The fixes for #170 and #171 follow.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
Captain Bob, 2026-11-12: "Build an appropriate test harness! Love the idea."
The kernel had no tests below the boots, so defects QEMU cannot provoke could
not be tested first. Plan: docs/v4.0.0/plans/2026-11-12-kernel-host-tests.md.
kernel/tests/: one host program per kernel source, built with that source as
it is, the kernel's flags (-std=c99 -Wall -Wextra -Werror), and fakes --
the console captured line by line, a deterministic RNG that can fail, and a RAM
disk whose reads, writes or flushes fail at chosen 1 KiB blocks.
make -C kernel/tests test runs them; SRC_<test>= runs a test against other
code, which is how a test is seen to fail against the code before a fix.
test_gpt.c, 12 checks: a table written and read back; 16, 17 and 18 used
entries against max 16 and an entry out of range after the 16th (#180); the
RNG, the first write, a later write and a flush failing (#168). Against gpt.c
before #168 and #180: 4 failures, each defect caught. Now: 0. Both runs in
logs/.../kernel-tests/. Not yet a protocol stage: to rule (the plan, step 5).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
Claude