DF-5599 — ichsmb IOPORT claim sizing vs ICH5+ BAR decode (Info, hardening)

File: sys/bus/smbus/ichsmb/ichsmb_pci.c (pass 2)

What this pack demonstrates

The driver requests 16 I/O-port bytes first (ichsmb_pci.c:233-234) but ICH5+ SMBus BARs decode 32 (64 under QEMU's ICH9 model — measured). On firmware-programmed BARs the newbus rl-count upgrade rescues the request (measured: 16 asked → 64 allocated); on BIOS-unprogrammed BARs (pci.c:2598-2610 records no rl entry → pci.c:4058-4061 pci_alloc_map honors count=16) the tail of the decode window stays hardware-decoded but rman-unowned.

Run (as root, inside the q35-rig guest with ichsmb+smb loaded)

sh run.sh

Expected output

bar   [20] = type I/O Port, range 32, base 0x700, size 64, enabled
...
            I/O ports:
                0x700-0x73f

(64 bytes allocated for a 16-byte request — the ulmax upgrade of subr_bus.c:2697-2700.)

Artifacts

run.sh, run.log, env.txt, fix.diff (32-first/16-fallback swap), VERDICT.md (both code paths), manifest.json, verdict.json.

DF-5599 VERDICT — 16-first IOPORT claim under-claims ICH5+ SMBus BARs (Info)

Bottom line

not_reproduced / impact none / certain (mechanism measured, hazard conditional). ichsmb_pci_attach asks for 16 I/O-port bytes first (ichsmb_pci.c:233-234), falling back to 32 (:236-237). Every ID in the driver's table from ICH5 (0x24d3) onward is an ICH5+ part whose SMBus BAR decodes 32 bytes (Intel datasheet; QEMU's ICH9 model even decodes 64 — measured size 64 via pciconf -lb). Two paths:

• Path A — firmware-programmed BAR (this rig): the PCI enumeration recorded a resource-list entry with the full BAR count (pci_add_map, pci.c:2551-2553 sizing + :2620 recording). The driver's default-window request (0, ~0, count=16) hits resource_list_alloc's upgrade count = ulmax(count, rle->count) (subr_bus.c:2697-2700), so the rman reserves the full decode (measured: requested 16 → allocated 0x700-0x73f = 64 bytes). No under-claim. Live-measured in run.log.
• Path B — BIOS-unprogrammed or BIOS-disabled BAR: pci_add_map deliberately records no rl entry when base == 0 or the BIOS wrote all-1s ("BIOS in an attempt to disable the resources", pci.c:2598-2610). pci_alloc_resource then routes the request to pci_alloc_map(..., count=16) (pci.c:4058-4061), which reserves only 16 bytes and programs the BAR base — while the hardware's fixed decode mask still covers 32 (or 64) bytes. The tail (BAR+0x10 .. BAR+0x1f) is then decoded by the controller but owned by nobody in the global I/O rman: any later 16-byte IOPORT allocation that lands there aliases into SMBus register space (both devices respond; reads merge, writes side-effect). Classic under-claim hazard; root/config-triggered, no in-tree claimant exists on the standard rig — hence Info.

Path B could not be exercised on this guest without changing firmware behavior (the rl entry is built at boot from the programmed BAR; SeaBIOS on q35 always programs it), so the finding stands on the code path plus the measured path-A upgrade.

Fix

fix.diff — swap the order: request 32 first, 16 as the fallback (largest documented decode first), so the pci_alloc_map path reserves the full window on ICH5+ while pre-ICH5 16-byte BARs still attach via the fallback. Info hardening; not kernel-rebuild-validated (fix_status= not_testable) since no bad behavior is reproducible on the standard rig.

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.