DF-4780 — corecstat attach-time kernel panic on original Atom (KKASSERT(sc->sc_version != 0) reachable for exactly the models probe() whitelists)

File: sys/dev/powermng/corecstat/corecstat.c Severity: Low (attach-time kernel panic; debug/INVARIANTS builds panic, production builds execute the "impossible" path) · Confidence: certain · Bucket: base:powermng

Root cause

corecstat_attach() routes original Atoms (sc_is_atom=1, sc_version=0) like this (corecstat.c:342-362):

    if (node != NULL && cpu == BSRCPUMASK(node->members)) {
        ... /* chip-representative cpu: create cpu_nodeN sensordev + PKG sensors */
    } else if (sc->sc_is_atom && sc->sc_version == 0) {
        return (ENXIO);                    /* non-representative cpus bail */
    }

    if (sc->sc_is_atom)
        corecstat_init_atom_cpu(sc, cpu);  /* KKASSERT(sc->sc_version != 0) !! */
    else
        corecstat_init_core_cpu(sc, cpu);

and corecstat_init_atom_cpu() opens with:

    /* No Core C-state residency counters on old Atoms */
    KKASSERT(sc->sc_version != 0);         /* corecstat.c:424 */

The else if only diverts non-representative cpus. The chip-representative cpu of an original Atom (models 0x1c/0x26/0x27/0x35/0x36 — all explicitly whitelisted by corecstat_probe() at corecstat.c:186-191) falls straight into corecstat_init_atom_cpu() with sc_version == 0 — violating the driver's own invariant on every original-Atom system (child_no of a CHIP node is its child count, sys/kern/subr_cpu_topology.c:125, and is ≥1 on any real topology, so the representative cpu always takes the first branch).

• INVARIANTS builds (KKASSERT active, sys/sys/systm.h:94-101 — LINT64-style configs, which include device corecstat): kernel panic at attach — boot-time doom if compiled in, panic on kldload otherwise. Reproduced on the guest: panic: assertion "sc->sc_version != 0" failed in corecstat_init_atom_cpu.
• Production builds (KKASSERT compiled out, systm.h:116-119): the "impossible" path executes — the representative original-Atom cpu registers Silvermont-only core C1 (MSR 0x660) / C6 (0x3fd) sensor probes. Both are rdmsr_safe-gated, so the damage is wrong-behavior, not corruption. Live-observed on the guest (console lines msr node0 core5 C1 res. (0x00000660) not available from a version-0 softc).

Reproduce (guest)

sh build.sh     # builds: patchcpu.ko (CPUID substitution) + corecstat.ko
                # (stock source + "#define INVARIANTS 1" line 1 == debug-kernel build)
sh run.sh       # kldload patchcpu; kldload corecstat
# expected: cpu0..4 "attach returned 6" (ENXIO), cpu5: 3 pkg MSR rejections, then
#           panic: assertion "sc->sc_version != 0" failed in corecstat_init_atom_cpu
#           -> DDB, guest down (vm.sh status => down)

patchcpu only substitutes the CPUID model advertisement (cpu_id -> 0x00030661, family 06h model 36h Cedarview — a model the driver itself whitelists); the panicked code is the stock, unmodified driver.

Fix

fix.diff guards the atom dispatch (if (sc->sc_version != 0)) so old Atoms get only their package sensors, restoring the author's documented design ("Only Package C-States available, no Core C-states", corecstat.c:267). Validated on the guest: same trigger, fixed module → no panic, no core C1/C6 probes, clean load/unload.

VERDICT — DF-4780

Reproduced? YES — attach-time kernel panic, twice, deterministically

Trigger on the QEMU/KVM guest (stock kernel, family-0x0F CPU): patchcpu.ko substitutes only the CPUID model advertisement (cpu_id → 0x00030661, family 06h model 36h Cedarview — a model corecstat_probe() itself whitelists at corecstat.c:189), then kldload corecstat.ko where corecstat.ko is the stock, unmodified driver source with #define INVARIANTS 1 on line 1 — i.e. exactly what any debug/INVARIANTS kernel build (LINT64-style; LINT64 contains device corecstat) compiles. Verified before loading that the module contains the KKASSERT panic string (grep -c assertion == 1).

Observed (full serial capture in panic.txt / run.log):

• cpu0..cpu4 (non-representative): device_probe_and_attach: corecstatN attach returned 6 — the atom-v0 else if ENXIO path (corecstat.c:355-357).
• cpu5 (chip representative, BSR of the CHIP node's members): package sensors probed via rdmsr_safe (PC2/PC4/PC6 lines, graceful), then

panic: assertion "sc->sc_version != 0" failed in corecstat_init_atom_cpu at corecstat.c:425 (pristine-tree line 424; +1 from the prepended define)

backtrace corecstat_attach → device_doattach → bus_generic_driver_added → devclass_add_driver → module_register_init → Debugger("panic"), all CPUs stopped, guest down in DDB, ssh hung (RUN_RC=124), vm.sh status ⇒ down.

Why it fires (logic, not environment)

corecstat_attach()'s else if (sc->sc_is_atom && sc->sc_version == 0) return (ENXIO) (corecstat.c:355-357) diverts only non-representative cpus. The chip representative of an original Atom takes the first branch (CHIP nodes always have ≥1 child: child_no is the child count, sys/kern/subr_cpu_topology.c:125) and then falls into corecstat_init_atom_cpu() whose first statement is KKASSERT(sc->sc_version != 0) (corecstat.c:424) — false by construction for exactly the five original-Atom models the probe whitelist names (corecstat.c:186-191). Every original-Atom system hits this at attach (boot-time panic if the driver is compiled in, kldload panic otherwise) on INVARIANTS builds.

Production builds (the honest gap)

KKASSERT is INVARIANTS-only (sys/sys/systm.h:94-119). On production kernels the assert is compiled out and the "impossible" path executes: the representative original-Atom cpu registers core C1 (MSR 0x660, Silvermont-only) and C6 sensor probes. Both are rdmsr_safe-gated (corecstat.c:594-603), so this is wrong-behavior, not memory corruption. Live-captured in run.log ("PRODUCTION-build fall-through": msr node0 core5 C1 res. (0x00000660) not available from a version-0 softc). Severity Low (panic class; DF-4735-comparable): the panic needs an INVARIANTS build, which DragonFly ships as its standard debug configuration and which LINT64-style configs make concrete (device corecstat + INVARIANTS). No unprivileged trigger: attaching the driver requires boot or root kldload on original-Atom-class hardware (or a VMM advertising those CPUIDs, as demonstrated).

Exploit chain: none — panic/DoS class (no memory corruption)

Fix validation: FIXED

fix.diff restores the author's documented design ("Only Package C-States available, no Core C-states", corecstat.c:267) by guarding the atom dispatch on sc_version != 0. Same trigger, fixed module (INVARIANTS define identical to the baseline build): no panic, module loads (FIXED_LOADED), cpu5 probes only the three package MSRs — the core5 C1/C6 lines are gone — clean kldunload, guest stays up (vm.sh status ⇒ up). A pleasing compiler certificate: with the fix, -O2 interprocedural analysis proves the assert condition always true (single static call site now guarded) and dead-code-eliminates the panic path — the fixed .ko no longer even contains the "assertion … failed in" string.

Guest state

Returned clean: vm.sh reset with-src after all runs; no kernel or /usr/src modifications persisted (trigger + fixed modules lived in /tmp only, on wiped disks).

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.