⬢ DragonFlyBSD Kernel Audit
← triage · dashboard
DF-5659

vkernel64 global.s:77-93 exports 8 gd_CMAP*/gd_PMAP1/gd_CADDR*/gd_PADDR1 aliases via GD_PRV_* macros for fields that DO NOT EXIST in the vkernel64 struct privatespace — un-restorable silent-vanish dangles (stale i386 lineage, absent even from the pc64 twin)

Summary

8 of the 21 vanished exports consume GD_PRV_* macros for per-CPU scratch-page fields the vkernel64 privatespace never had - the contract is un-satisfiable for these (no field to offsetof), so unlike DF-5658 no ASSYM line can fix them. Actively misleading: a maintainer restoring the missing ASSYMs hits a compile error on exactly these 8 and likely abandons the whole restoration; the dangling U GD_PRV_* pollutes every VKERNEL64 symbol table read by in-process ddb/kgdb. delete-the-aliases fix (bundled with DF-5658's validated diff).

Discussion (0)

No comments yet.

PoC verification

Evidence pack

findings/poc/DF-5659 · 10 files
FileTypeDescriptionSize
README.md — 1.7 KB ↓ raw
verdict.json — 2.6 KB view raw
build.sh — 113 B view raw
run.sh — 112 B view raw
nm_global_pristine.txt — 1.0 KB view raw
final_binary_baseline.txt — 1.1 KB view raw
final_binary_fixed.txt — 688 B view raw
assym.fixed.s — 1.3 KB view raw
fix.diff — 2.7 KB view raw
env.txt — 563 B view raw
README.md
↓ download raw

DF-5659 — vkernel64 global.s exports 8 gd_CMAP/gd_PMAP1/gd_CADDR/gd_PADDR1 aliases via GD_PRV_* macros for fields that DO NOT EXIST in the vkernel64 struct privatespace — un-restorable silent-vanish dangles (stale i386 lineage)

Twin/sibling of DF-5658, split out because the remediation differs: these 8 cannot be fixed by adding ASSYM lines (the fields are absent from sys/platform/vkernel64/include/globaldata.h:107-114 — struct privatespace holds only mdglobaldata + filler + idlestack, no prv_CMAP*/CADDR*/PMAP1/ PADDR1), so the only correct fix is deleting the aliases.

Evidence

Identical run as DF-5658 (same guest, same VKERNEL64 build tree, same rules — full pack in ../DF-5658/):

  • nm_global_pristine.txt: U GD_PRV_CMAP1/2/3, U GD_PRV_PMAP1, U GD_PRV_CADDR1/2/3, U GD_PRV_PADDR1 in the real-rule-built global.o; the .globl gd_CMAP1, … exports (global.s:77-78) are absent from nm.
  • final_binary_baseline.txt: all 8 ride into the linked vkernel64 binary as zero-relocation undefined symbols; link exit 0.
  • fix.diff (shared with DF-5658, validated): deletes global.s:77-78 and the 8 .set lines at global.s:86-93 → final_binary_fixed.txt: zero undefined GD_* of any kind, link green.

Why it matters

Same silent-vanish mechanism as DF-5596/DF-5658, but these 8 are actively misleading: the pc64 twin has no such block (it is i386 heritage), a maintainer "restoring the missing ASSYMs" hits a compile error on exactly these (no field to offsetof), and the exports have been dangling in every VKERNEL64 build ever made with zero diagnostics. Dead-code removal + the DF-5658 guard restore together make the genassym↔global.s contract total (26/26 macros accounted for).

Fix verification

fixed
baseline reproduced→ patch + rebuild →patched clean

Baseline: 8 undefined GD_PRV_ macros, 8 vanished exports, build green. After deleting the aliases (fix.diff): zero undefined GD_ of any kind in global.o and the final binary, link exit 0.

fix.diff (global.s hunks), final_binary_fixed.txt, ../DF-5658/fixbuild.log
↓ fix.diffper-fix-DF-5659

Confirmed kernel references

Detail

Evidence (decisive lines)

nm_global_pristine.txt (8 U GD_PRV_* at object level); final_binary_baseline.txt (8 zero-relocation undefineds in final binary, link exit 0); final_binary_fixed.txt (0 U after deletion); ../DF-5658/VERDICT.md for the full run narrative

PoC changes

No separate PoC authored — verified inside the DF-5658 evidence run (shared build tree); this pack carries the decisive extracts.

Verified recommended fix

Delete global.s:77-78 and the eight .set lines at global.s:86-93 (included and validated in DF-5658's fix.diff)

Verdict

Verified within the DF-5658 build-diff run: the real-rule-built vkernel64 global.o carries U GD_PRV_CMAP1/2/3, U GD_PRV_PMAP1, U GD_PRV_CADDR1/2/3, U GD_PRV_PADDR1 while the .globl'd gd_CMAP/PMAP1/CADDR/PADDR1 exports (global.s:77-78,86-93) are absent from nm entirely; all 8 ride into the linked vkernel64 binary as zero-relocation undefined symbols with the link exit 0. struct privatespace for vkernel64 (globaldata.h:107-114) contains no prv_CMAP/CADDR/PMAP1/PADDR1 fields, so unlike DF-5658's 13 these cannot be restored by adding ASSYM lines — the aliases are stale i386 lineage absent even from the pc64 twin. Deletion validated as part of fix.diff: zero undefined GD_* remain after the fix, link green.