DF-5409 — cpu_sanitize_frame whitelists PSL_VM_UNSUPP: the DF-5335 gate is incomplete for EFLAGS.VM

What (the bug)

The vkernel's frame sanitizer, sys/platform/vkernel64/x86_64/cpu_regs.c:311-320:

316:    frame->tf_rflags &= (PSL_RF | PSL_USERCHANGE | PSL_VM_UNSUPP);

The mask deliberately KEEPS PSL_VM_UNSUPP (0x20000, the EFLAGS.VM bit, with a "XXX VM (8086) mode not supported?" comment). The pc64 host mirror (sys/platform/pc64/x86_64/machdep.c:916) is identical — confirmed by disassembly of the running guest kernel (disasm_host.txt: and $0x274dd5,%eax; 0x20000 ∈ mask).

cpu_sanitize_frame is the gate the trap.c pass-2 audits cited as blocking the DF-5335 (espfix / bad-frame-at-iretq) route for the vkernel: every go_user → vmspace_ctl(VMSPACE_CTL_RUN) re-entry into (guest-)user mode passes through it (sys/vm/vm_vmspace.c:298), and it correctly forces CS/SS and masks IOPL/NT/… — but not VM.

Consequence

A VM-set rflags survives BOTH sanitizers (the vkernel's and the host's) and is loaded by the host kernel's return-to-user:

• reached structurally by ANY frame source — sigreturn (see DF-5408), set_regs is blocked (EFL_SECURE), but vmspace_ctl(RUN) frames pass straight through the whitelisting mask (verified: 20,000 consecutive vmspace_ctl RUNs with rflags=0x20246 accepted, run_suite.log mode 2),
• on hardware/VMMs that enforce the SDM rule (iretq attempting VM in long mode → #GP(0)), that is a guest-user-triggerable kernel-mode #GP at the host doreti iretq — the IDTVEC(prot) / doreti_iret_fault special case, i.e. exactly the code path whose robustness DF-5335 questions;
• on the rig's CPU (Intel Skylake under KVM) the bit is silently masked at iretq/SYSRET (proved with iretvm.c — see DF-5408's pack), so no fault manifests here.

There is no legitimate way for VM to be set in a 64-bit user rflags: the kernel's own sys_sigreturn calls it "VM (8086) mode not supported" and tries (DF-5408: ineffectively) to strip it. The sanitize mask keeping it is a completeness gap in the gate.

Precondition

• sigreturn vector: none (any guest user).
• direct vmspace_ctl vector: vm.vkernel_enable=1 inside the vkernel (guest-root sysctl — the standard state for running any nested vkernel); then any guest process can vmspace_create + vmspace_ctl (no priv check — sys/vm/vm_vmspace.c:150-192).

Verified

Same rig and run as DF-5408 (shared evidence):

• baseline vkernel binary: mask 0x274dd5 (disasm_vk_baseline.txt);
• running HOST kernel (pc64): mask 0x274dd5 (disasm_host.txt);
• runtime: mode 2 loop — 20k VM-frames through both sanitizers, all accepted, nested contexts executed at the poisoned rip (frame loaded, not rejected);
• fixed vkernel: mask 0x254dd5 (VM removed — disasm_vk_fixed.txt).

Recommended fix

Drop PSL_VM_UNSUPP from the mask in BOTH copies (vkernel64 cpu_regs.c:316 and pc64 machdep.c:916) — fix.diff in DF-5408's pack contains both hunks plus the sigreturn-side fix.