Skip to content

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

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions