# 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:

| site | MSR | raw op | gate |
|------|-----|--------|------|
| acpi_pst_amd1x_check_p_states1:227 | 0xc0010064..6b | rdmsr | vendor AMD, family ≥ 0x10, APMI bit (0x80000007) |
| acpi_pst_amd1x_set_pstate:259 | 0xc0010062 | wrmsr | same, plus per-state MSR-enabled check |
| acpi_pst_amd1x_get_pstate:280 | 0xc0010063 | rdmsr | same |
| acpi_pst_intel_init:506/:509/:511 | 0x1a0 | rd/wrmsr | vendor Intel, CPUID2_EST |
| acpi_pst_intel_set_pstate:530/:533 | 0x199 | rd/wrmsr | same |
| acpi_pst_intel_get_pstate:555 | 0x198 | rdmsr | same |

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.