CR4 SMEP/SMAP/UMIP and CR0.WP never enabled (code exists, verified safe to wire)

[eKisNonos]

The kernel boots with SMEP, SMAP, UMIP and CR0.WP all OFF, even though correct enable code exists, because the enable functions have zero callers. The live CR4 write (arch/x86_64/asm/start.S:33) sets only OSFXSR|OSXMMEXCPT. Three separate written paths (memory/mmu/mmu/init.rs:36, memory/hardening/manager/verify/protection.rs:19, process/userspace/transitions.rs:26) are all unreachable. The handoff even advertises SMEP/SMAP/UMIP as active, a claim the kernel never enforces.

Risk left open: without SMEP the kernel can execute a user page (ret2usr); without SMAP it can be tricked into reading attacker-controlled user memory as trusted; without CR0.WP a kernel write bug can modify its own read-only .text, defeating the bootloader's W^X; without UMIP ring 3 can sgdt/sidt/sldt/smsw/str.

SMAP is verified safe to enable now: every kernel access to user-owned memory in this codebase goes through DIRECTMAP_BASE + phys (usercopy/direct.rs:29, signal frame push/pop, ELF segment load, demand-zero and COW fill), never through a user virtual address, so SMAP will not spuriously fault and STAC/CLAC are unnecessary. WP is safe too (no runtime .text patching found). NXE and EFER.SCE are already set, and the kernel image is already W^X, so this is the highest-value lowest-effort hardening step.

Widening: CPUID-gate and OR the bits into CR4/CR0 in init_core_systems (the code in mmu/init.rs is idempotent), and apply the same bits per-core in the AP path.

[eKisNonos]

Confirmed still present on main, and worth doing next. src/arch/x86_64/boot/constants_cr.rs defines CR4_SMEP, CR4_SMAP, CR4_UMIP and CR0_WP, and nothing in the kernel writes any of them. The only CR4 write on the boot path is in src/arch/x86_64/boot/validation/sse_enable.rs, which sets the SSE bits, and the SMEP and SMAP enabling in src/arch/x86_64/smm/advanced/sandboxing.rs runs only in the SMM path. nonos-bootloader/src/handoff/prepare/flags.rs sets the SMEP and SMAP handoff flags and boot/security/platform.rs prints CPU mitigations: SMEP+SMAP+NX, so the boot log reads as though this were already on. It is not.

[eKisNonos]

One more thing that makes this cheaper than it looks. The usual reason SMAP is hard to turn on is that the kernel dereferences user pointers and every such site then needs stac and clac around it. This kernel does not do that. src/usercopy/direct.rs moves every byte at DIRECTMAP_BASE plus the physical frame, never through the user virtual address, after src/usercopy/walk/access.rs has walked the tables and checked the USER and WRITABLE bits itself. The directmap alias is a supervisor mapping, so a copy through it is a supervisor access to a supervisor page and SMAP does not fire. There is no stac or clac anywhere in the tree and, given that design, none is needed. So SMEP, SMAP, UMIP and CR0.WP can all be set at boot behind a CPUID check, and the work is the wiring plus a boot on real hardware, not an audit of user pointer dereferences.