DF-5346 — SMAP missing from the hypervisor feature blacklist in identify_cpu()

Where

sys/platform/pc64/x86_64/identcpu.c

664:    if (cpu_high >= 7) {
665:        cpuid_count(7, 0, regs);
666:        cpu_stdext_feature = regs[1];
667: 
668:        /*
669:         * Some hypervisors fail to filter out unsupported
670:         * extended features.  For now, disable the
671:         * extensions, activation of which requires setting a
672:         * bit in CR4, and which VM monitors do not support.
673:         */
674:        if (cpu_feature2 & CPUID2_VMM) {
675:            cpu_stdext_disable = CPUID_STDEXT_FSGSBASE |
676:                         CPUID_STDEXT_SMEP;
677:        } else {
678:            cpu_stdext_disable = 0;
679:        }

The comment defines the rule: under a VMM, mask CPUID.7.EBX bits whose activation writes a CR4 bit that VM monitors may not support. SMAP (CPUID_STDEXT_SMAP, bit 20) qualifies exactly — its activation writes CR4.SMAP in cpu_implement_smap() (machdep.c:344-346, invoked from cpu_startup when cpu_stdext_feature & CPUID_STDEXT_SMAP) — but it is not in the mask. SMEP is masked; SMAP is not. A hypervisor that advertises SMAP without supporting CR4.SMAP (the same class of bug that motivated the mask — VirtualBox advertising SMEP circa 2014) makes the kernel take a #GP writing CR4 during early boot → boot panic.

On-guest documentation (QEMU 7.2.22, KVM)

-cpu qemu64,+smap,check=off boots:

Features2=0x80202001<SSE3,CX16,x2APIC,VMM>          <- VMM detected
Structured Extended Features=0x100000<SMAP>          <- SMAP advertised under VMM
CPU Special Features Installed: SMAP                 <- blacklist passed it through

…reaching login: cleanly (QEMU/KVM implements CR4.SMAP, so no fault — expected). This documents the pass-through; the fault case requires a CR4.SMAP-faulting hypervisor, which stock QEMU cannot emulate.

Class: defense-in-depth consistency / lying-CPUID boot DoS. Speculative — no known shipping hypervisor currently trips it; filed because the file's own rule says this bit belongs in the mask (and hw.cpu_stdext_disable users can add it manually at the loader prompt).

Fix

        if (cpu_feature2 & CPUID2_VMM) {
            cpu_stdext_disable = CPUID_STDEXT_FSGSBASE |
                         CPUID_STDEXT_SMEP |
+                        CPUID_STDEXT_SMAP;
        }

DF-5346 — VERDICT

Status: not_reproduced (by design of the harness): the fault requires a hypervisor that advertises CPUID.7.EBX.SMAP under the VMM bit but faults the CR4.SMAP write. QEMU/KVM implements CR4.SMAP, so the +smap boot passes through the blacklist and boots cleanly — which itself documents the finding's core claim: SMAP is NOT masked under VMM while SMEP/FSGSBASE are (identcpu.c:674-676), contradicting the mask's own rule at :668-673 ("extensions, activation of which requires setting a bit in CR4").

Evidence: boot-kvm-smap.log lines 35/38/40: Features2=0x80202001 (VMM present) Structured Extended Features=0x100000 (bit survived the blacklist) CPU Special Features Installed: SMAP (cpu_implement_smap() ran)

Impact ceiling: boot-time #GP panic under a buggy/malicious hypervisor — same class as DF-5345 and the same class the in-file rdmsr_safe guard at identcpu.c:683-696 was added for. Speculative (no known shipping hypervisor currently trips it); severity Low, hardening-consistency.

Fix validation: not_testable — cannot construct the faulting hypervisor with stock QEMU 7.2 (CR4.SMAP is always accepted).

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.