[Japabu]

The kernel root-file unsafe sweep (#215) filed four findings it judged to be
decisions past a documentation sweep. All four are decided and fixed here, one
commit each, and all four issue files are deleted with their citations.

The through-line is one rule, which the four sites now state where they are
rather than where they were filed: the kernel forms no Rust reference over
memory another writer can change, and every single-word read of such memory is
one read. Three of the four are that rule; the fourth is the bound that was an
argument.

Per commit

ed816e49 — the futex word and the crash dump read once. Both were a plain
*ptr where user_ptr.rs's copy_in uses read_volatile on a stated
argument. The futex one is a predicate completion::wait_until may evaluate
more than once, so a plain load is one LLVM may hoist out of the loop that calls
it. The rule is now a paragraph in user_ptr.rs's module header, naming the
bulk windows as the deliberate exception.

Negative control: none can exist, and that is the finding's own point — the
change constrains the compiler, not the machine, so on x86 both spellings behave
identically and no guest test can tell them apart.
Oracle: the emitted assembly at both sites, --emit=asm on the same tree with
and without the change. scheduler::futex_wait::{closure#0}: .loc 22 760 29 movl (%rsi), %eax before, .loc 82 2153 9 movl (%rax,%rdx), %eax after.
process::dump_crash_diagnostics::{closure#0}: .loc 18 1925 23 movq (%rsi), %rdx before, .loc 82 2153 9 movq (%rdx,%rax), %rdx after. File 82 is
rust/library/core/src/ptr/mod.rs — the load is still exactly one mov, and
after the change it is the one core::ptr::read_volatile emits.

c159aa7b — the initrd's extents are bounded by the initrd.
InitrdBacking held the image's base and the file's size, so
file_offset_to_ptr computed an address for any block the btree named with
nothing to compare it against — and the btree is inside that same image, so a
corrupt initrd read whatever the bootloader placed after it. It holds the image
now (bcachefs::SliceBlockIO, made Copy) and reads through a new
SliceBlockIO::block, which is the one thing that knows both numbers.
file_backing.rs and bcachefs_adapter.rs contain no unsafe at all any more;
mount_initrd takes the image rather than (ptr, len), so the one claim about
the region is SliceBlockIO::new's. block.raw() as usize * BLOCK_SIZE was
also an unchecked multiply in all four image-backed readers, which under the
kernel's overflow-checks = true was a kernel panic from a number an image
chose.

Negative control: bcachefs/src/block_io.rs's slice_bounds, five host unit
tests over the pure arithmetic. Mutated SliceBlockIO::block back to an
unchecked multiply and a bare slice index:
test result: FAILED. 21 passed; 4 failed — a_block_past_the_end... (range end index 16384 out of range for slice of length 12288),
a_block_that_starts_inside_and_ends_outside... (range end index 12288 out of range for slice of length 8193), a_block_number_whose_byte_offset_wraps...
(attempt to multiply with overflow), an_empty_image_holds_no_block_at_all
(range end index 4096 out of range for slice of length 0). Restored: 25
passed.
Oracle: every boot. /bin/init and every program it spawns is demand-paged
out of the initrd through this exact path, and there is no second route to the
root filesystem — so the green suite is a differential check of the new bound
against the extent lists a real mkfs produces. bcachefs's own 51 integration
tests cover byte_range's other three call sites.

77134593 — the demand-paging fill is bounds-checked. PageAlloc handed
out a bare *mut u8, so handle_page_fault's file-backed copy and its
relocation pass were in bounds by argument (the relocation one derived a whole
4 KiB page from offset < page_2m, which says nothing about the 4096 bytes past
offset). The decision the finding asked for was one abstraction or four,
and the answer is one and it is not a new one: mm::KernelSlice already is a
bounded window that hands out no &mut [u8], and what was missing was a safe
way to build one. PageAlloc::window() is that, sized from the allocation the
type owns — which is exactly the fix shape
issues/design-debt/kernelslice-from-raw-cannot-check-itself.md already named
for PageAlloc; that issue keeps its other two call sites and gains a dated
section. UserStack holds one too, so USER_STACK_SIZE is named once.

Negative control: one mutation, two trees, cargo test --test toyos-build -- mmap_prot. The fill writes at page_offset + page_2m, one frame past the
allocation. With the window: DOUBLE PANIC: the cpu was already in PageFault; first: panic at src/mm/region.rs:65:9 — KernelSlice::check, before a byte
leaves the frame. With the bare pointer this commit replaces: no bound fires at
all, and the failure surfaces later and elsewhere as SEGFAULT tid=0: read unmapped address at 0x0 at _start+0x0 — userland faulting on a page of zeros,
after the kernel has written into whatever the PMM handed out next. Restored:
PASS mmap_prot (160ms).
Oracle: allocator_stress, mmap_stress, mmap_prot, std_mmap,
std_tls_dlopen, fault_gates — and every boot, since every PIE this machine
runs is filled and relocated through these two sites.

0e63b5ee — the inbox page is built before it is shared. Two things were
wrong. The order: create called map_into and then built the RingLayout
and both RingHeaders through &mut, so from the map onward a sibling thread
could write the same bytes. The page is laid out before it is mapped now, and
the ordering is enforced by SharedMemObject::phys_before_mapping, which
asserts the region is mapped nowhere. The shape: &RingHeader was a data race
on ring_size (a plain u32 the process can store to) whatever the kernel read
through it, and &Submission — all integers, therefore Freeze — really did
carry noalias, so the one-* copy was one LLVM could split back apart. Header
words are now reached one &AtomicU32 at a time (AtomicU32::from_ptr, sound
over shared memory because an atomic's UnsafeCell is what withdraws
noalias), and a submission is a read_volatile of the whole entry. No Rust
reference to that page survives; every memory ordering is unchanged.

Negative control: phys_before_mapping's assert. Moved write_ring_page back
below map_into, cargo test --test toyos-build -- abuse_inbox:
PANIC: panicked at src/object/shm.rs:166:9: shm koid 15: the region is mapped into a process already, so a kernel write through the direct map is not exclusive, backtrace phys_before_mapping <- inbox::create <-
sys_inbox_setup, in logd's Poller::new. /bin/logd builds a poller before
the machine is ready, so the reversed order does not red one test — it stops the
boot. Restored: PASS abuse_inbox (42ms).
Oracle: abuse_inbox, inbox_cancel_wakes, poller_capacity,
port_poll_churn, log_poll_outlives_a_close, metal_sim_ipc_hostile_peer,
and every daemon in every boot — all of which park in submit on a completion
posted through the accessors this rewrites. kernel-loom re-run and unchanged:
no model names this ring, and the release/acquire edges are byte-identical.

Gates

Run after merging origin/main at 5ceb8641 (the drivers sweep, #210):

• cargo run -- --build-only — exit 0.
• cargo test — test result: ok. 272 passed, 272 total (50.4s), 53 held back for the nightly tier. No FAIL, STALL, INVL or ALONE line.
• cargo test --workspace --exclude toyos-build — exit 0, 100 test result: ok
  lines, no failures. That run includes kernel-loom's eight models
  (inbox, log_publish, log_record, log_wake, reap_gate, sleep_lock,
  ticket_lock, tlb_shootdown).

No red was adjudicated; there were none.

Filed, not fixed

issues/design-debt/poller-borrows-the-rings-the-kernel-writes.md — writing the
kernel half of the inbox fix surfaced the mirror image in the SDK:
toyos/src/poller.rs builds &RingHeader, &mut Submission and &Completion
over the same page, with the kernel as the second writer. The two entry
borrows are Freeze types and therefore carry noalias. Same two moves apply;
the SDK was out of this task's scope.

issues/design-debt/kernelslice-from-raw-cannot-check-itself.md gains a dated
section saying PageAlloc has its safe constructor now and the loader and
DmaPool still do not, so it stays open.