kernel: ring 0 cannot execute a user page

SMEP turns the classic escalation — divert kernel control flow into a page
the attacker wrote — from a silent takeover into an immediate fault with
the offending address in the log. The bit is per-core state, so it is set
where the syscall MSRs already are: in the per-CPU bring-up both the boot
processor and every application processor run on their way in. A core that
climbed the trampoline without it would be a hole no boot log would show,
which is why the SMP case now reads CR4 on each core it lands on and
requires every one of them to be hardened, not just the one that printed
the banner.

Enabling it that early is only safe because nothing ring 0 executes is
mapped for ring 3, and that had to be established rather than assumed:
kernel text carries only its ELF flags, the physmap is no-execute, the
trampoline page is mapped supervisor and the core running it has not
enabled the bit yet, and the boot processor turns it on while still on the
loader's tables — which map nothing user-accessible at all. The one
indirect call in the kernel takes a kernel address.

The CPUID probing that was scattered across the timer code becomes a small
shared helper, since the feature question is now asked from two places and
each wanted the same maximum-leaf guard. Absence is tolerated and reported,
like the IOMMU: danos still boots on a machine without the feature, and
says which one it is.

The test harness starts asking QEMU for a CPU that has the bit at all —
its default model has neither SMEP nor SMAP, so the code would otherwise
have been unreachable in every run. No case behaved differently under the
richer model.

Suite 112/112, with a new case that maps an executable user page, calls
into it from the kernel, and requires the fault the CPU is supposed to
raise.

docs/security-track-plan.md

@@ -36,11 +36,11 @@ plain `main` checkout always tells the truth about where the work is.**
 
 | | |
 |---|---|
-| Working on | **H2** — SMEP (group 4) |
-| Branch carrying it | `feat/security-group-4` (cut next) |
+| Working on | **HS** — SYSRET canonical-RIP guard |
+| Branch carrying it | `feat/security-group-4` (pushed to origin) |
 | On `main` | everything through P4c — groups 1, 2 and 3 merged |
-| Awaiting merge | nothing |
-| Suite | 111 cases, all passing |
+| Awaiting merge | H2 — lands with the group 4 merge |
+| Suite | 112 cases, all passing |
 | Last updated | 2026-08-01 |
 
 A checkbox below means the phase met its definition of green and was
@@ -80,7 +80,7 @@ group boundary.
   nobody holds. New `badge-scope` case, two processes of one fixture, every
   refusal paired with a control; suite 111/111)
 - [x] **merge** group 3 → main, push
-- [ ] **H2** — SMEP on every core
+- [x] **H2** — SMEP on every core (shared CPUID helper; CR4 bit 20 set in the per-CPU bring-up both the BSP and every AP run, asserted per core by the smp case; ring-0-executes-user-pages audit clean incl. the pre-paging window on the loader's tables; fail-open with a posture line; `-cpu max` added to the harness since QEMU's default model has neither bit; new `fault-smep` case; suite 112/112)
 - [ ] **HS** — SYSRET canonical-RIP guard
 - [ ] **H3** — SMAP + boot-patched `clac`; `-cpu max` in the harness; negative tests
 - [ ] **merge** group 4 → main, push