DF-5484 — raw rdmsr/wrmsr P-state MSRs: fatal #GP on CPUID-lying platforms

sys/platform/pc64/acpica/acpi_pstate_machdep.c touches fixed MSRs with raw rdmsr()/wrmsr() gated only by CPUID bits:

Intel: 0x1a0 (:506/:509/:511), 0x199 (:530/:533), 0x198 (:555)   [gate: CPUID2_EST]
AMD:   0xc0010064..6b (:227), 0xc0010062 (:259), 0xc0010063 (:280)
                                                         [gate: family>=0x10 + APMI bit]

A #GP in kernel mode is a fatal trap. The first P-state transition happens unattended at boot (acpi_pst_postattach -> acpi_pst_global_set_pstate), again on every root px_global/px_domN.select sysctl write, and on every type-0x80 _PPC notify fixup.

Build (on the guest)

sh build.sh     # msrprobe.ko, msrprobe2.ko, rawpst.ko (bsd.kmod.mk)

Run (KVM -cpu host)

dfbsd-qemu/vm.sh down
QEMU_EXTRA="-cpu host" dfbsd-qemu/vm.sh up 150
sh run.sh       # kldload rawpst.ko

Expected (observed)

rawpst: safe probe: rdmsr_safe(0x199) -> error 0 val 0
rawpst: safe probe: wrmsr_safe(0x199, val) -> error 14
rawpst: raw driver sequence (pstate_machdep.c:530-533), cval=0x0e00 ...

Fatal trap 9: general protection fault while in kernel mode
...
Stopped at      rawpst_modevent+0xb7:   wrmsr
db>

Guest dead in DDB; vm.sh status -> down. Full console: panic.txt / panic_run_fullconsole.log. Safe-accessor inventory of all six MSR sites: run_probe.log / msrprobe2.log.

Honest gap (DF-5155 methodology)

No QEMU config on this host can advertise CPUID2_EST (KVM: host Xeon E3-1275 v5 lacks CPUID.01H:ECX bit 7 and KVM_GET_SUPPORTED_CPUID does not virtualize it; TCG masks est as unimplemented), so the driver path with the md engaged is not constructible here; rawpst executes the driver's exact instruction pair instead. On any VMM that advertises EST without virtualizing PERF_CTL, the stock driver takes this trap at boot.

VERDICT — DF-5484

Reproduced? YES (panic primitive) — with the family-standard honest gap:

the driver path itself is unreachable on this VMM because no QEMU CPU

config can advertise CPUID2_EST; the exact driver instruction sequence

was executed in kernel context instead (DF-5155/DF-5160 methodology).

What the audited code does

sys/platform/pc64/acpica/acpi_pstate_machdep.c touches fixed MSRs with RAW rdmsr()/wrmsr() — a #GP in kernel mode is a fatal trap (panic/DDB). The only gating is CPUID bits read at probe time:

If the VMM (or CPU) advertises the feature bit without virtualizing the MSR, the first P-state transition takes the fatal trap. That transition happens (a) unattended at boot (acpi_pst_postattach → acpi_pst_global_set_pstate), (b) on every sysctl hw.acpi.cpu.px_global=<freq> / px_domN.select write (root), (c) on every ACPI type-0x80 _PPC notify fixup.

Evidence on this guest (KVM -cpu host, Skylake Xeon E3-1275 v5)

msrprobe2 (safe accessors only):

msrprobe2: cpu_vendor_id 32902 cpu_id 0x506e3 cpu_feature2 0xf7fab223 (CPUID2_EST clear)
msrprobe2: rdmsr(0x1a0) -> error 0 val 0x1
msrprobe2: wrmsr(0x1a0,|EST) -> error 0
msrprobe2: rdmsr(0x1a0) -> error 0 val 0x10001 -> EST bit STUCK (init would succeed)
msrprobe2: wrmsr_safe(0x199, 0x0e00) -> error 14 (raw wrmsr at pstate_machdep.c:533 would #GP panic)

i.e. on this very VMM: MISC_ENABLE (0x1a0) works, PERF_STATUS (0x198) works, IA32_PERF_CTL (0x199) writes take #GP. rawpst then executed the exact acpi_pst_intel_set_pstate sequence (:530-533):

rawpst: safe probe: rdmsr_safe(0x199) -> error 0 val 0
rawpst: safe probe: wrmsr_safe(0x199, val) -> error 14
rawpst: raw driver sequence (pstate_machdep.c:530-533), cval=0x0e00 -- expect Fatal trap 9

Fatal trap 9: general protection fault while in kernel mode
cpuid = 4; lapic id = 4
instruction pointer     = 0x8:0xffffffff826000b7
...
Stopped at      rawpst_modevent+0xb7:   wrmsr
db>

Full console in panic_run_fullconsole.log / panic.txt. Guest dead in DDB, vm.sh status -> down.

The honest gap

EST cannot be advertised on this QEMU under any acceleration: KVM drops it (host Xeon E3-1275 v5 does not set CPUID.01H:ECX bit 7 — server SKU — and KVM_GET_SUPPORTED_CPUID does not virtualize it; TCG masks it as unimplemented: "TCG doesn't support requested feature: CPUID.01H:ECX.est"). So the driver path with the md engaged is constructible only with a kld substituting the CPUID advertisement (estforce.ko in the DF-5483 pack does exactly this for the IO-port variant) — but under TCG the MSR 0x199 write is virtualized (no #GP), and under KVM the CPUID bit cannot be raised. Any VMM that advertises EST without virtualizing PERF_CTL (the DF-4735/DF-5155/ DF-5160 lying-CPUID class; several KVM versions expose EST on client SKUs of Intel hosts) gets the boot-time fatal trap. Identical situation and calibration to DF-5155 (perfbias, Low, root-gated/likely) and DF-5160 (aperf, Low, boot-time/likely).

Impact

Kernel panic / fatal trap 9 → DDB → system down. Unattended variant fires at boot whenever the tables provide _PSS/_PCT with Fixed-Hardware control (perfectly normal firmware). No memory corruption (a fault, not a write primitive). Severity Low (VMM/misconfigured-platform precondition), confidence likely.

fix.diff

Authored (fix.diff): all six raw sites converted to rdmsr_safe/wrmsr_safe with error propagation (check → EINVAL, init → EIO, set → error, get → NULL). With the fix, a lying VMM yields a dead P-state domain and a kprintf, not a fatal trap. fix_status=not_testable: rebuilding would change the driver, but the trigger configuration (EST advertised + PERF_CTL faulting) is not constructible on this VMM; the fixed behavior (return error 14, no trap) is exactly what the safe-probe halves of msrprobe2/rawpst demonstrated live in this pack.

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.