DF-5667 — vkernel64 is_globaldata_space() blesses all SMP_MAXCPU(256) reserved per-CPU slots while only ncpus are ever mapped

File: sys/platform/vkernel64/platform/globaldata.c (pass 2)

What this is

An Info-grade latent API hazard, runtime-proven: on a stock VKERNEL64, is_globaldata_space() (and therefore the MI kernacc()) returns TRUE for ~7.9 MB of reserved but unmapped kernel virtual address space (the per-CPU slots of CPUs that do not exist). Today no in-tree caller can be harmed by this (the sole kernacc() consumer chain on the vkernel, /dev/kmem → kvm_access_check(), page-table-validates every page before consulting kernacc()), but the lie is load-bearing API surface: any current or future direct consumer of the MI kernacc() on a vkernel would take the TRUE at face value, touch the page, and panic the vkernel.

Reproduce (on the audit guest, as root)

# 1. build the vkernel (current HEAD needs the two defsyms: the vkernel64
#    links like a userspace binary — conf/Makefile:23 — and does not get the
#    __build_id_start/__build_id_end PROVIDEs its ldscript would provide)
cd /usr/src && make -j6 nativekernel KERNCONF=VKERNEL64 || true
cd /usr/obj/usr/src/sys/VKERNEL64
make -n kernel.debug 2>/dev/null | grep '^cc .*kernel.debug' > /tmp/linkcmd.txt
sh -c "$(cat /tmp/linkcmd.txt) -Wl,--defsym,__build_id_start=0 -Wl,--defsym,__build_id_end=0"
sh vk_image.sh          # builds /vkroot.img (minimal root + devfs)
sysctl vm.vkernel_enable=1
mkdir -p /var/vkernel

# 2. baseline run: boots a 2-vCPU vkernel, enters DDB via
#    sysctl debug.enter_debugger=ddb (DDB args MUST be 0x-hex; ddb input
#    radix is 16), drives call-probes at raw nm-derived addresses, then
#    scans every page of the window through /dev/kmem.
sh vk_probe4.sh         # decisive baseline: see run.log

# expected decisive lines (run.log):
#   db> call <is_globaldata_space>(0x8000420123, 0x800042012b)   -> 1   (dead slot blessed)
#   db> call <kernacc>(0x8000420123, 8, 1)                       -> 1   (MI kernacc lies)
#   db> call <pmap_kextract>(0x8000420123)                       -> 123 (garbage PA, pmap.c defect)
#   db> call <kvm_access_check>(0x8000420000, 0x8000421000, 1)   -> e   (EFAULT — PTE loop saves /dev/kmem)
#   db> call <kernacc>(0x8000400040, 8, 1)                       -> 1   (live slot, intended)
#   db> call <pmap_kextract>(0x8000400040)                       -> 197040 (real guest-phys)
#   PG 0 OK addr=549760008192        (slots 0+1 readable: 16 pages = 2*32KB)
#   PG 16 EF addr=549760073728       (first dead slot page -> EFAULT, uniformly, no porous pages)

# 3. fix validation: apply fix.diff to the guest's /usr/src copy, rebuild
#    globaldata.o, relink as above, rerun the identical driver:
#    is_globaldata_space(dead) 1 -> 0, all live probes unchanged, scan
#    unchanged. See run.fixed.log.

Rig notes

• vkernel: /usr/obj/usr/src/sys/VKERNEL64/kernel.debug -m 512m -r /vkroot.img -n 2 -e init_path=/bin/vkinit -s (console via mkfifo; adapted from the DF-5655 rig).
• The vkernel's DDB has no symbol table (kdb_init() is #if 0'd in init.c) — all probes use raw nm-derived addresses.
• Measured layout (this build): CPU_prvspace = 0x8000400000, sizeof(struct privatespace) = 0x8000 (32 KB), window = 256*32 KB = 8 MB reserved, slots 0..1 mapped (ncpus=2). kernel_map spans [0x8000000000, 0x1000000000000) — see VERDICT.md for the implications.

DF-5667 VERDICT — vkernel64 is_globaldata_space() blesses all 256 reserved per-CPU slots; only ncpus are ever mapped

Status: reproduced (latent hazard, runtime-proven). Impact: none in-tree today (Info). Fix validated.

1. Root cause

sys/platform/vkernel64/platform/globaldata.c:82-89:

int
is_globaldata_space(vm_offset_t saddr, vm_offset_t eaddr)
{
    if (saddr >= (vm_offset_t)&CPU_prvspace[0] &&
        eaddr <= (vm_offset_t)&CPU_prvspace[MAXCPU]) {
        return (TRUE);
    }
    return (FALSE);
}

MAXCPU == SMP_MAXCPU == 256 (sys/cpu/x86_64/include/param.h:71-72). The KVA window [CPU_prvspace, CPU_prvspace+256*S) is only reserved (init.c:727-733 bumps virtual_start by sizeof(struct privatespace) * SMP_MAXCPU); actual pages are mapped only for CPUs that come online — cpu0 in init_globaldata() (init.c:735-748) and each AP in start_all_aps() (mp.c:407-419). optcpus (-n, bounded 1..MAXCPU at init.c:389-397) determines ncpus; on the default -n 2 boot, 254 of the 256 slots (7.94 MB of the 8 MB window, S measured = 32 KB) are reserved-but-unmapped KVA, and is_globaldata_space() blesses every byte of them.

The function's only consumer is kernacc() (sys/vm/vm_glue.c:119), whose comment explicitly documents the special case ("The globaldata space is not part of the kernel_map proper"). On pc64 the same function is #if 0'd out and replaced by a DMAP check (sys/platform/pc64/x86_64/machdep.c:2964-2976) because there the globaldata space is in kernel_map — the live check is a vkernel-specific contract, and it validates 128x more address space than exists.

2. Runtime proof (guest, stock VKERNEL64 + DDB call probes)

Rig: nativekernel-built kernel.debug, -m 512m -n 2, console via mkfifo, DDB entered with sysctl -w debug.enter_debugger=ddb, driven with raw nm-derived addresses (the vkernel's DDB has no symbol table — kdb_init() is #if 0'd in init.c; DDB args must be 0x-hex because ddb's input radix is 16). Measured: CPU_prvspace = 0x8000400000, ncpus = 2, sizeof(struct privatespace) = 0x8000 (16 live pages), window = 8 MB.

Baseline (run.log, values in hex per ddb radix):

So: the hazard (kernacc TRUE on unmapped KVA) reproduces; the only in-tree composed path (/dev/kmem → kvm_access_check) is protected solely by the PTE-loop ordering — a kernacc()-believing consumer would receive silent TRUE and panic the vkernel on touch. No such consumer exists in-tree today ⇒ Info.

3. Fix validation (same guest, same driver, single-function patch)

fix.diff bounds the check by ncpus (slots 0..ncpus-1 are exactly the mapped ones; DF vkernels have no CPU hotplug, ncpus is fixed at mp_start() long before any /dev/kmem open).

kernacc(dead) still returns 1 on the patched kernel — not via is_globaldata_space (now 0) but via kernacc's kernel_map fallback: the vkernel's kernel_map spans [0x8000000000, 0x1000000000000) (min/max read via /dev/kmem at the static map struct, 0xf15680; nentries=0x37), and vm_map_check_protection() blesses the unmapped KVA in between (probed: kernacc TRUE at 0x8000300123 / 0x8000420123 / 0x8000c10123 — below, inside, above the window). That residual bless is a vm-subsystem property (vm_glue.c/vm_map.c/vm_machdep.c — different files), orthogonal to this finding; the practical gate for /dev/kmem remains kvm_access_check's pmap_kextract loop. Recorded here as a follow-up lead, not re-scoped.

4. Negative results (what was hunted and killed in this file)

• globaldata_find() (globaldata.c:58-63): KKASSERT bound is live (options INVARIANTS in VKERNEL64, config:60); every MI caller loops < ncpus. No out-of-range index reaches CPU_prvspace[].
• cpu_gdinit() (globaldata.c:66-79): byte-identical to pc64's (machdep.c:2944-2959); the td_sp -= 8; *(void**)td_sp = cpu_idle_restore push lands at idlestack_top − sizeof(struct pcb) − 24 — in bounds (vkernel64 pmap_init_thread, platform/pmap.c:1003-1009, sets td_sp = td_pcb − 16); gd_prvspace is set before both call sites (init.c:795, mp.c:423); cpu_idle_restore/cpu_lwkt_switch exist (swtch.s:598/678). A 128-byte /dev/kmem dump of slot0's mdglobaldata cross-validated the layout (gd_prvspace self-pointer at +0, gd_idlethread at +0x30).
• Vanished-export fields (DF-5658: gd_savefpu/gd_fpu_lock/gd_currentldt/ gd_ss_eflags/gd_common_tssd/gd_tss_gdt): zero-initialized via bzero(gd, sizeof(*gd)) (mp.c:422, init.c:787) — semantically correct defaults; no C runtime consumers in vkernel64 (only global.s aliases = DF-5658's filed territory). Not re-reported.
• PRIVATESPACE_SEGPAD (include/globaldata.h:102): dead macro in vkernel64 (no consumers; its PAGE_SIZE*4 term counts pc64's CPAGE/PPAGE pages that the vkernel struct lacks) — header-side stale lineage adjacent to DF-5659; noted, not a .c finding.
• Sizing chain closed: -n parse bounds optcpus 1..MAXCPU (init.c:389-397, usage_err otherwise); naps = ncpus−1; start_all_aps touches only slots 1..naps ⊂ 256-slot reservation. No config-supplied size can overflow the window.

5. Follow-up leads surfaced (other files, out of scope here)

1. pmap_kextract() returns garbage for PDE==0 (vkernel64 platform/pmap.c:731-748): pa = (*pmap_pde_to_pte(&pde=0, va) & VPTE_FRAME) | (va & PAGE_MASK) → runtime-proven 0x123 for an unmapped KVA with nonzero page offset — a bogus nonzero "physical address" instead of 0. (The DMAP+0 read itself is safe: guest-phys page 0 is the bootstrap PML4 with only two nonzero entries — create_pagetables(), pmap.c — and those indices read as frames here.) Affects any unaligned-VA pmap_kextract consumer; page-aligned loops are unaffected. Deserves its own pmap.c pass-2 entry.
2. kernacc()/kernel_map bless all unmapped vkernel KVA (vm_glue.c + vkernel kernel_map span [0x8000000000, 0x1000000000000)): kernacc TRUE at three probed unmapped addresses; kvm_access_check's PTE loop is the only real gate. vm-subsystem pass-2 material.
3. VKERNEL64 does not link on current HEAD: sysctl_build_id (kern/kern_mib.c:103-134) references __build_id_start/__build_id_end unconditionally, but the vkernel64 links like a userspace program (platform/vkernel64/conf/Makefile:23, no -T ldscript.x86_64), so the ldscript's PROVIDEs never materialize. Build regression, not security; worked around here with --defsym during relink.

6. Environment

Guest: DragonFly 6.5-DEVELOPMENT #0 (X86_64_GENERIC, built Jul 2 2026), KVM; vkernel = nativekernel VKERNEL64 + defsym relink, 2 vCPUs, 512 MB; vm.vkernel_enable=1. Full logs: run.log (baseline), run.fixed.log (patched), build.log (nativekernel + manual relink), driver*.log.

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.