How Hardware Memory Keys (MPK) and Pre-Launch Code Scanning (SFI) Work Together

Why One Defense Layer Is Not Enough in Ring 0

When people first hear that PangeaOS runs all services inside one shared address space at the processor's highest privilege level (Ring 0), they usually ask one of two questions:

1. "If you have hardware Memory Protection Keys (MPK), why do you need to scan the program's machine code before it runs?"
2. "If you already scan the program's machine code before it runs (SFI), why do you also need hardware Memory Protection Keys?"

The answer is that each mechanism covers the exact blind spot of the other. Together, they form a lock-and-key partnership that neither could achieve alone.

1. What Hardware Memory Keys (MPK) Do Best—and Their One Blind Spot

Modern x86-64 processors allow the operating system to assign one of 16 keys (K0 through K15) to every 4-Kilobyte page of memory. While Service Domain 3 is running, the CPU's PKRU register unlocks only K3. If Domain 3 computes a dynamic pointer at runtime that accidentally points into Domain 4's memory or the kernel's K0 memory, the CPU hardware blocks the read or write in zero extra clock cycles.

The Blind Spot of MPK: Because the PKRU register is designed to be fast, the instruction that changes it—wrpkru (encoded as the three bytes 0F 01 EF)—is an unprivileged instruction! If a program running in Ring 0 (or even Ring 3) were allowed to execute the bytes 0F 01 EF, it could simply write 0x0000_0000 into PKRU and unlock every key in the system. Similarly, via the xrstor instruction (if Bit 9 is enabled in EAX), a program could load a forged PKRU value from memory.

2. How Pre-Launch Code Scanning (bincheck-core) Closes That Blind Spot

This is where Pre-Launch Code Inspection (SFI & bincheck-core) steps in. Because PangeaOS enforces strict Write XOR Execute (W^X) on every page table entry, a running service can never write new code or modify existing code pages at runtime.

Before any service binary is allowed to run, bincheck-core decodes its executable section from start to finish along exact instruction boundaries:

• It verifies that the byte sequence 0F 01 EF (wrpkru) and 0F 01 EE (rdpkru) never appear as instructions anywhere in the domain binary.
• It verifies that xrstor, cli, mov cr3, wrmsr, and unverified indirect jumps never appear in the domain binary.
• In addition, our runtime gate (sanitize_xsave_restore_mask) strips Bit 9 (PKRU) from all XSAVE/XRSTOR state masks.

3. Why Combining Both Gives the Best of Both Worlds

By combining pre-launch code scanning with hardware Memory Protection Keys:

1. bincheck-core guarantees that a service domain can never forge its hardware keycard (PKRU), disable interrupts, or jump outside its approved control flow.
2. Hardware MPK (PKRU) guarantees that every memory read and write at runtime is checked by the CPU silicon against the active keycard (K1–K12), protecting Domain 0 (K0), page tables (K13), and all other service domains at full hardware speed.