boot2

commit 7a7f7f34a97ad45e343138d69aea575a9bd2a870
parent afba887f0c618419dd2bd013b6326c27d03b9bd9
Author: Ryan Sepassi <rsepassi@gmail.com>
Date:   Wed,  6 May 2026 11:33:22 -0700

seed-kernel: amd64 pool B must not overlap kernel image

ARCH_USER_POOL_B_PA was 0x34c00000 with a 768 MB pool size, putting
pool B's PA range across the kernel's 0x40000000 load address. When
sys_spawn swapped to pool B and load_elf zeroed the child's BSS
through the alt-pool VA mapping, ~176 MB into the loop the writes
landed on the running kernel's .text/IDT/data, faulting the kernel
through a now-corrupt IDT. boot3 amd64 was the first stage to call
sys_spawn so it was the first stage to hit it.

Move pool B to 0x4b000000 (just above ARCH_KERNEL_HEAP_END), giving
0x4b000000..0x7b000000 — well clear of the kernel and within the
2 GB RAM. aarch64/riscv64 already place both pools strictly above
the kernel and weren't affected.

Diffstat:
M
seed-kernel/arch/amd64/arch.h
 | 
8
+++++++-

1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/seed-kernel/arch/amd64/arch.h b/seed-kernel/arch/amd64/arch.h
@@ -18,7 +18,13 @@
 #define ARCH_STATIC_VIRTIO_MMIO_COUNT  8
 
 #define ARCH_USER_POOL_A_PA 0x04c00000UL
-#define ARCH_USER_POOL_B_PA 0x34c00000UL
+/* Pool B must start above ARCH_KERNEL_HEAP_END (0x4b000000): the kernel
+ * image is loaded at PA 0x40000000 and the kheap extends to 0x4b000000,
+ * so a pool whose PA range crosses 0x40000000 lets sys_spawn's load_elf
+ * (zeroing the new image's BSS through the alt-pool VA mapping) trample
+ * the running kernel. aarch64/riscv64 don't hit this because their
+ * kernels are loaded above both pools. */
+#define ARCH_USER_POOL_B_PA 0x4b000000UL
 #define ARCH_USER_POOL_SIZE 0x30000000UL
 #define ARCH_USER_VA_LO     0x00200000UL
 #define ARCH_USER_VA_HI     0x30200000UL