# DF-4928 — corepower probe family-gating fall-through (Info, hardening)

**File:** `sys/dev/powermng/corepower/corepower.c`
**Class:** incorrect CPU gating → probe passes on non-family-06 CPUs; raw
`rdmsr()` on the attach path where `rdmsr_safe()` was available.
**Severity:** Info (no demonstrated security impact — every subsequent MSR
read remains gated by `corepower_try()`/`rdmsr_safe`; live-verified benign).
**Verified live:** yes — on the QEMU/KVM audit guest whose CPU reports
`Origin="GenuineIntel" Family=0xf Model=0x6b`.

## The issue

`corepower_probe()` (corepower.c:154-205) wraps the model whitelist in

```c
	if (cpu_family == 0x06) {
		switch (cpu_model) { ... default: return (ENXIO); }
	}
```

For a CPU whose family is **not** 0x06 (this guest: family 0xf) the switch
is *skipped* — probe falls through to the only remaining gate,
`corepower_try(MSR_RAPL_POWER_UNIT)` (rdmsr_safe). If that MSR read happens
to succeed (real family-0xf Netburst hardware does not implement RAPL, but
hypervisors commonly service unknown MSRs — QEMU/KVM does here), probe
succeeds and `corepower_attach()` runs on a CPU that cannot have the
feature, executing the **raw** `rdmsr()` at corepower.c:273 before failing
with `ENXIO` at :331-332 (`sc_have_sens == 0`).

Observed live (run.log):

```
CPU: QEMU Virtual CPU version 2.5+ ;  Origin="GenuineIntel"  Id=0x60fb1  Family=0xf  Model=0x6b
corepower0: <CPU On-Die Power Usage Estimation> on cpu5
device_probe_and_attach: corepower0 attach returned 6     <- ENXIO from attach
(no sensors - as expected)
```

The same skip-guard shape exists in `corepower_attach()` (:226-271) — there
it is harmless because `sc_have_sens` stays 0 → ENXIO.

Why this matters even though it is benign today: this is the exact pattern
that produced the reproduced #GP family in `coretemp` (DF-4735) — probe
gating that trusts one MSR check and attach/refresh paths that then use
raw `rdmsr()`. In corepower every post-probe read is either
`rdmsr_safe()`-verified (each sensor MSR at :289-329) or, for
`MSR_RAPL_POWER_UNIT` at :273, verified by probe's `corepower_try()` —
so no #GP is reachable; the finding records (a) the inverted-looking
family guard and (b) the defense-in-depth miss, with a two-line fix.

## Reproduce (on the audit guest, as root)

```
sh trigger.sh        # kldload corepower; capture dmesg; kldunload; uptime
```

Success criterion: dmesg shows the probe/attach pair above on a
family-0xf CPU, no sensors attach, no panic, guest alive after unload.

## Files

- `trigger.sh` / `build.sh` (no-op) / `run.log` / `env.txt`
- `fix.diff` — reject non-family-06 in probe; `rdmsr_safe` at attach:273
- `VERDICT.md`, `manifest.json`, `verdict.json`