fix(kernel): the block chain's fast RAM is cleared on the v3 path

It came from kmalloc, which does not clear what it hands out; only the
ramdrive beside it was cleared.  A VM's BLOCK on blocks 0 to 2047 read
whatever had been in the kernel's heap.  The v4 path already cleared its
own.

Accepted on the v3 configuration: amd64, aarch64 and riscv64 reach the
zuse prompt, no UNKNOWN WORD, PARITY:M7.1a hash 0x08873e0f44b7cb2a on all
three, as before.  logs/20261007-140609, -140735, -140946.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
rajames
2026-10-07 14:10:49 -04:00
co-authored by Claude Opus 5.5
parent 193523d873
commit a425f738a4
5 changed files with 27458 additions and 3 deletions
+5
View File
@@ -669,6 +669,11 @@ static void kernel_main_deep(BootInfo *boot_info) {
/* Pre-zero the ramdrive buffer (no memset in freestanding context) */
size_t krd_i;
for (krd_i = 0; krd_i < KRD_BUF_SIZE; krd_i++) krd_buf[krd_i] = 0;
/* And the fast RAM, LBN 0..2047. kmalloc does not clear what it
* hands out, so without this a VM's BLOCK read whatever had been in
* the kernel's heap (fixed 2026-10-07; found while the v4 node was
* given these blocks, docs/v4.0.0/MESH.md step 6). */
for (krd_i = 0; krd_i < BLK_RAM_SIZE; krd_i++) blk_ram_buf[krd_i] = 0;
/* Init block subsystem (RAM + ramdrive) */
capsule_blk_init(mama_vm, blk_ram_buf, BLK_RAM_SIZE, krd_buf);
}