fix(security): validate syscall buffers against the caller VAS

[forkwright]

Summary

Closes the syscall-isolation hole in #871: memguard::validate_user_buffer checked only that a numeric range lay between KERNEL_END and RAM_END. Because syscalls execute at PL1 over an identity-mapped DRAM, a numerically valid pointer could reference another process's pages, allocator and kernel structures, a PROT_NONE page, or a read-only mapping PL0 could not touch — and every fd, socket, pipe, futex and time syscall treated that bounds check as authority before dereferencing.

validate_user_range(ptr, len, Access) keeps the numeric check as a cheap first gate, then walks the range page by page against the calling process's own L2 descriptors, requiring PL0 permission in the requested direction.

Two questions, not one

Permission needs both halves, and each alone admits the other's failures:

• l2_entry_is_user answers ownership (the software NG tag).
• AP/APX answer reachability.

A PROT_NONE user page is user-owned and carries AP_KERNEL_ONLY — so it is indistinguishable from a kernel fill by AP alone, and indistinguishable from a readable user page by ownership alone. Direction is the other half: a read-only mapping is a legitimate source and an illegitimate destination, and the old guard accepted both.

Why the mapping gate is conditional, and why that is not a bypass

The gate asks what the caller's page tables say, which only has an answer while a user process is current. A new process::current_user_page_table decides that positively — a non-zero PID holding a table that is not PID 0's kernel global L1. A PL0 caller always has one by construction, so the numeric-only path is not reachable from userspace.

A bare current_page_table() != 0 would have been wrong here: PID 0 is a real entry whose table is the kernel L1, so that test would validate user pointers against kernel mappings — accepting exactly the addresses the check exists to reject.

elf.rs deliberately keeps the numeric guard

It places an image for a process that has no page table yet, through the kernel identity map. A caller-VAS check there would test the loading process's mappings against the loaded process's addresses and reject every legitimate segment. The reason is recorded at the call site so it does not read as an oversight.

sys_execve argv

Validated only the first byte of each argv string while scanning up to MAX_ARG_LEN - 1 bytes, so a string starting near the end of a mapping was scanned past it — the instance recorded in #871's own follow-up comment. It now validates the full scan window, the same conservative policy path_ptr already used.

Testing

Host builds have no MMU and no user address space, so the permission logic and the range walk are factored as pure functions and tested directly rather than through the live walk. Fifteen tests, built around the cases that would otherwise pass silently:

• a PROT_NONE page accepted by an ownership-only check
• a kernel page with permissive AP accepted by an AP-only check
• AP_FULL with APX set, which reads as writable but is not
• a hole after a valid first page (a start-only check accepts this)
• a read-only page late in a write span
• an unaligned start, and a span ending one byte past a page boundary — both asserting exactly which pages were consulted

Descriptors are minted by the real prot_to_l2_flags, the sole producer of user L2 entries, rather than hand-assembled.

docs/target-test-ledger.toml is updated: memguard 13 → 28 tests, and it now carries a fidelity note, because adding l2_entry/page_table references makes the module target-sensitive by the ledger's own pattern. The note states plainly what host tests cannot reach — the live walk — and that a target witness proving a PROT_NONE buffer is refused on device is still owed.

What this does not do

#871 stays open. Its remaining acceptance is fault containment (an invalid address must return EFAULT rather than taking a privileged fault), centralized copyin/copyout, the permission-transition race cases, and the target witness above. This closes the validation clause; it does not close the issue.

No hardware, firmware, or raw-device operation is involved. Builds and tests run on GitHub CI.

Refs #871