# DF-5588 VERDICT — kenv RSDP acceptance in sdt_probe (pass 2)

**Status: REPRODUCED (certain). Impact: panic (boot). File:
sys/platform/pc64/acpica/acpi_sdt.c:71-77, deref at :109-115.**

## 1. Root cause

`sdt_probe()` (SYSINIT SI_BOOT2_PRESMP SI_ORDER_FIRST, acpi_sdt.c:63-118)
has three RSDP discovery paths:

1. **kenv hint** (acpi_sdt.c:71-77): `kgetenv_ulong("hint.acpi.0.rsdp")` →
   `pmap_mapdev(rsdp_paddr, PAGE_SIZE)` → `goto found_rsdp`. **No
   validation of any kind** — not the 8-byte "RSD PTR " signature, not the
   checksum, not Length, not Revision, and not the address itself.
2. EBDA scan (acpi_sdt.c:79-94) — signature checked (acpi_sdt.c:130).
3. E0000-FFFFF scan (acpi_sdt.c:96-106) — signature checked.

At `found_rsdp` the mapped bytes are consumed wholesale
(acpi_sdt.c:109-115): `rsdp->Revision` picks RSDT-vs-XSDT and
`RsdtPhysicalAddress`/`XsdtPhysicalAddress` become the root of every
`sdt_search()` walk used by madt_probe (acpi_madt.c:96), fadt_probe
(acpi_fadt.c:95) and srat_probe (acpi_srat.c:75).

Pass-1 boundaries: DF-1114 filed the *scanned* RSDP (signature-only match
in `sdt_rsdp_search`, missing checksum/Length); DF-1113 filed the unbounded
table-`Length` KVA panic. **Neither covers the kenv branch, which is a
separate acceptance that performs less validation than either** (it skips
even the signature match DF-1114's path has). This finding files that gap
and demonstrates it live.

## 2. Why the pmap path faults on a bad address (R4)

`pmap_mapdev_attr()` (sys/platform/pc64/x86_64/pmap.c:6192-6219) allocates
KVA with `kmem_alloc_nofault` (pmap.c:6201) and writes raw `pa` into PTEs
(pmap.c:6208). With `hint.acpi.0.rsdp=0x800000000000` on the qemu64 CPU
model (physical address bits = 40), PTE bits ≥ 40 are reserved → the first
read of the mapping (`rsdp->Revision`, acpi_sdt.c:109) takes a kernel #PF
on a nofault-entry KVA → `panic: vm_fault: fault on nofault entry`
(observed in run.bogus_addr.panic.log, immediately after the bootverbose
line "ACPI SDT: RSDP in kenv hint").

## 3. R1/R2 — acceptance is total (evidence)

* R1 baseline (valid "RSD PTR " + control MADT: BSP+2 APs+IOAPIC):
  `ACPI SDT: RSDP in kenv hint`, `madt_lapic_probe: lapic_count=3`,
  IOAPIC configured from the crafted table.
* R2 (signature = `de ad be ef de ad be ef`, v1 checksum = 0xAA, same
  chain): **identical** — `lapic_count=3`, crafted IOAPIC consumed
  (run.nosig_control.boot.log). The 8 signature bytes and the checksum are
  never consulted on this path.

Guest has 6 vCPUs; a 3-CPU enumeration proves the crafted MADT (not the
firmware one) was consumed.

## 4. R3 — the family keystone (evidence)

Same invalid-signature RSDP + DF-5430's `bsp_omit` MADT →
`panic: assertion "arg.bsp_found" failed in madt_lapic_pass2`
(run.nosig_bsp_omit.boot.log, panic.txt). I.e. every crafted-table bug in
DF-5430..5433 and DF-5583 is reachable through an RSDP that fails *every*
ACPI validity check — this `if` is the keystone of the planted-ACPI rig.

## 5. Threat model (why Medium, not higher)

The hint is set from `/boot/loader.conf` / the loader prompt — a boot-owner
(equivalent to root/boot-disk write or console access). No unprivileged
in-guest path reaches it (sdt_probe runs at SI_BOOT2_PRESMP; runtime kenv
cannot affect it). Consistent with DF-1113 (Medium, same trust boundary):
the direct impact is a deterministic boot brick / crafted-table injection
from one line, plus the enabling role for the whole family.

## 6. Fix validation + the cross-file residual

`fix.diff` (validated `git apply --check -p0` against the read-only sys/
tree): bound `rsdp_paddr < ptoa(Maxmem)` before mapping (Maxmem is set in
`getmemsize()` during `init386`, machdep.c:2284/2899, i.e. before any
SYSINIT) and require signature + `Revision <= 2` before accepting; on
failure unmap and fall through to the firmware scan.

Patched-kernel build: clean, 358 s, 0 errors (fix_build.log excerpt;
/usr/src copy, `make -j8 nativekernel KERNCONF=X86_64_GENERIC`).

Patched-kernel runs:
* invalid-RSDP + bsp_omit blob → `sdt_probe: kenv RSDP failed validation,
  falling back to firmware scan` → `RSDP not in EBDA` → `RSDP in BIOS mem`
  → `madt_lapic_probe: lapic_count=6` (real firmware MADT) — **the
  bsp_found panic is GONE** (fix_run.log).
* hint → zeroed RAM (the "typo" case): previously the zero RSDP was
  accepted, `RSDT paddr == 0` printed, and the boot wedged before SMP; on
  the patched kernel it is rejected and full 6-CPU SMP bring-up proceeds.

**Residual (separate file, do not fix here):** `AcpiOsGetRootPointer()`
(sys/platform/pc64/acpica/OsdEnvironment.c:66-81) hands the *same*
unvalidated hint to ACPICA. Observed live: (a) patched kernel, crafted
chain → ACPICA consumed it and faulted at `AcpiTbLoadNamespace+0x36`
(fix_run.log tail); (b) patched kernel, zeroed hint → ACPICA table walk
hangs late in boot (serial log frozen after "ACPI: S? 0x0 ... F000FF53").
The complete remediation needs the same validation in that acceptance (or
one shared validator). This matches the orchestrator's existing
"acpi.c leads: unvalidated RSDP kenv" item; R4-style out-of-RAM hints would
also fault inside ACPICA's mapping until that sibling is patched, which is
why fix_patched_reproduced=false is reported for end-to-end boot while the
audited file's own behavior (R3 scenario) is verified fixed.

## 7. Negative results (classes checked and killed in this file)

* sdt_rsdp_search (acpi_sdt.c:120-135): scan bound `i < size - 36` keeps
  the 36-byte struct inside the mapped window; 16-byte step is spec-
  compliant; signature checked. (Checksum gap = DF-1114, not re-filed.)
* Walk array bounds (acpi_sdt.c:194-214, 255-274): entry sizes correct
  (XSDT u64 / RSDT u32 via sizeof); `nent = (Length-36)/entry` cannot
  overflow int (max 1073741814); entries at byte 36+8i/36+4i always lie
  inside the Length-sized mapping → no OOB relative to the mapping.
* Mapping lifecycle (acpi_sdt.c:137-157): map/unmap size pairs are
  consistent (same Length re-read from a still-mapped, boot-time-static
  table); header probe map/unmap of 36 bytes matches pmap_unmapdev's
  rounding; children mapped/unmapped one at a time; no refcounts to leak;
  all not-found paths unmap. `sdt_sdth_map` rejects Length<36, and the
  walk only returns tables it successfully mapped, so consumer
  `KKASSERT(madt != NULL)`-style asserts cannot fire.
* Consumers all guard `sdt_search()==0` (acpi_madt.c:97, acpi_fadt.c:96,
  acpi_srat.c:76-78) → no accidental page-0 mapping.
* `ebda_addr` (machdep.c:2275-2276, BIOS BDA word<<4) is bounded <1 MB;
  DF-1114-class firmware input only.
* The `AcpiOsTableOverride` DSDT replacement (sys/dev/acpica/Osd/OsdTable.c:63-82)
  is loader-blob-fed, different file — cross-referenced, not filed here.
* Bonus observation (contrib ACPICA, out of tree scope): a valid-RSDT chain
  with **no FADT/DSDT** makes the stock kernel fault at
  `AcpiTbLoadNamespace+0x36` (`cmpl $0x54445344,0x14(%rbx)`) during acpi0
  attach — see run.valid/‌nosig boot logs; reportable against the
  acpica-family lead, not acpi_sdt.c.

## 8. Reproduce summary

    ./build.sh
    vm.sh reset with-src
    vm.sh run_root 'printf "hint.acpi.0.rsdp=0x40000000\nboot_verbose=YES\n" >> /boot/loader.conf; sync'
    vm.sh down
    QEMU_EXTRA="-device loader,file=$PWD/nosig_bsp_omit.bin,addr=0x40000000,force-raw=on" vm.sh up 150
    vm.sh log    # -> panic: assertion "arg.bsp_found" ...  (through an INVALID-signature RSDP)

    # R4: loader.conf hint.acpi.0.rsdp=0x800000000000, boot with no blob:
    #     -> panic: vm_fault: fault on nofault entry

Guest left clean: `vm.sh reset with-src` after all runs (verified: Jul 2
snapshot kernel active, no hint in loader.conf, real-firmware lapic_count=6).

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