DF-5658 — vkernel64 genassym.c emits only 5 of the 26 GD_ macros global.s consumes: 13 silently-vanished .set exports for fields that EXIST (DF-5596 twin, 13×), plus the 8 GD_PRV_ dangles split out as DF-5659

Evidence class: build-diff on the guest's VKERNEL64 build tree (the vkernel is a user program linked with plain cc — see sys/platform/vkernel64/conf/Makefile:23-25).

What to run

Everything was executed on the QEMU guest (DragonFly 6.5-DEVELOPMENT, env.txt) whose /usr/src is MD5-identical to the audit tree for all 9 files involved (genassym.c, global.s, swtch.s, locore.s, fork_tramp.s, conf/files, VKERNEL64 config, globaldata.h, thread.h — MD5s in env.txt).

# 1. create the VKERNEL64 build tree
cd /usr/src/sys/config && config VKERNEL64          # -> /usr/src/sys/compile/VKERNEL64
cd /usr/src/sys/compile/VKERNEL64

# 2. regen assym.s through the REAL kern.post.mk rules (see build.log)
make assym.s global.o                                # both exit 0, -Werror
nm global.o                                          # -> nm_global_pristine.txt / run.log

# 3. independent value check (offset_check.c, exact genassym CFLAGS)
sh $(sed 's|genassym.c|/tmp/offset_check.c|' checker.cmd) -Wno-nested-externs -o /tmp/oc.o
cc /tmp/oc.o -o /tmp/oc && /tmp/oc                    # -> offset_check.out (65 lines)

# 4. end-to-end link proof (build-id stub works around the unrelated
#    kern_mib.c __build_id buster — see VERDICT.md "Incidental")
cc -g -Wl,--export-dynamic -o /tmp/kernel.dangleproof $(make -V SYSTEM_OBJS) \
   vers.o /tmp/bidstub.o -pthread -Wl,--hash-style=sysv -Wl,-z,max-page-size=0x200000
nm /tmp/kernel.dangleproof | grep ' U GD_'           # -> 21 undefined
objdump -r /tmp/kernel.dangleproof | grep -c GD_     # -> 0 relocations

# 5. fix validation
cd /usr/src && patch -p1 < fix.diff                  # genassym.c +13 ASSYM, global.s -8 PRV
cd sys/compile/VKERNEL64 && rm -f genassym.o assym.s global.o
make assym.s global.o locore.o swtch.o fork_tramp.o  # -> fix_build.log
# relink as in step 4 -> /tmp/kernel.fixed
nm /tmp/kernel.fixed | grep -c ' U GD_'              # -> 0
nm /tmp/kernel.fixed | grep -E ' [ADB] gd_'          # -> 18 exports (fix_run.log)

Expected results

Key restored values (independent-TU verified, offset_check.out): gd_currentldt=0x3f14 (right after gd_spending=0x3f0c+gd_sdelayed=0x3f10, matching globaldata.h:74-78 field order), gd_reqflags=0x18, gd_cnt=0xa8, gd_intr_nesting_level=0xa0, gd_common_tssd=0x3a80, gd_tss_gdt=0x3a88, gd_common_tss=0x3a98, gd_savefpu=0x3b00, gd_fpu_lock=0x3f00, gd_fpending=0x3f04, gd_ipending=0x3f08, gd_ss_eflags=0x3f48.

Files

• run.log / nm_global_pristine.txt / final_binary_baseline.txt — the dangle proof (object + final binary)
• build.log / checker.cmd / checker_build.log — regen + independent-TU build
• offset_check.c / offset_check.out — 44 ASSYM values verified; CHECK_*/MISSING_* extras
• assym.pristine.s / assym.fixed.s — 44 → 57 defines
• vkbuild.log — FULL untrimmed 547-object VKERNEL64 build incl. the link failure (__build_id_*)
• link.log / link2.log — baseline/patched final-binary links
• fixbuild.log / fixbuild2.log / fix_run.log / final_binary_fixed.txt — fix validation
• fix.diff — git-apply-clean against pristine sys/ (verified with git apply --check)
• env.txt — guest uname/cc/ncpu + source MD5 identity

DF-5658 VERDICT

Status: reproduced (build-diff evidence class). Impact: none at runtime today — no relocation or C consumer references the vanished exports; the defect is a silently-broken C↔assembly contract at 21× the scale of the pc64 twin (DF-5596), on the platform whose link (plain userland cc) has the weakest undefined-symbol gate. Confidence: certain.

The claim under test

Pass-2 task_log lead (2026-10-08): "vkernel64 global.s:65 has the identical GD_CURRENTLDT dangle". Verified — and it is not alone: an exhaustive used-vs-defined inventory over ALL assym.s consumers in the VKERNEL64 build (global.s, locore.s, swtch.s, fork_tramp.s — plus in_cksum2.s/monitor.s/ bzeront.s which include assym.s but consume no macros) shows:

• sys/platform/vkernel64/x86_64/global.s consumes 26 distinct GD_* macros (lines 52-97) for its .globl/.set export block;
• sys/platform/vkernel64/x86_64/genassym.c defines only 5 of them (GD_CURTHREAD :77, GD_CPUID :78, GD_CPUMASK :79, GD_OTHER_CPUS :80, GD_NPXTHREAD :121);
• 21 dangle, split by restorability into this finding (13) and DF-5659 (8):

Every live displacement use in the real consumers resolves (swtch.o, fork_tramp.o, locore.o: zero ASSYM-shaped undefined symbols — the PCB_CR3/PCB_EXT/MSR_FSBASE/MSR_KGSBASE/PCB_USERLDT uses in swtch.s:348,369, 429,440,464 are all inside #if 0 dead blocks). The entire defect class is concentrated in global.s's .set export block, where gas resolves the missing macro to an undefined external symbol: the alias and its .globl export silently vanish, assembly exits 0, -Werror stays silent.

Reproduction (guest, DragonFly 6.5-DEVELOPMENT #0, cc 8.3, 6 vCPU)

1. Source identity. All 9 involved files MD5-identical between audit tree and guest /usr/src (env.txt).
2. Real-rule regen. config VKKERNEL64 → /usr/src/sys/compile/VKERNEL64; make assym.s via kern.post.mk:73-79 emitted exactly 44 defines (assym.pristine.s), regeneration byte-identical (determinism). make global.o (kern.post.mk .s rule, -Werror) → exit 0, and nm global.o (nm_global_pristine.txt): exactly 5 backed exports (gd_curthread=0x8, gd_cpuid=0x48, gd_cpumask=0x50, gd_npxthread=0x3a90, gd_other_cpus=0x70) + U for all 21 missing macros — U GD_CURRENTLDT among them, the lead confirmed at the object level — while gd_reqflags, gd_common_tss, gd_currentldt, … (the 21 .globl exports) are absent from nm entirely.
3. End-to-end link. The vkernel is linked as a user program (conf/Makefile:23-25: cc -Wl,--export-dynamic … -pthread, no -T ldscript). Linking all 547 SYSTEM_OBJS + vers.o that way (link.log/final_binary_baseline.txt) → exit 0 with the 21 U GD_* riding into the final binary with zero relocations (objdump -r/readelf -r → 0 GD_* entries) — precisely why the userland link never fails on them.
4. Fix. fix.diff adds the 13 restorable ASSYM lines to genassym.c and deletes the 8 GD_PRV_ aliases from global.s (DF-5659). Rebuilt with the same rules (fix_build.log): assym.s 44→57 defines (assym.fixed.s); global.o now exports 18 gd_* symbols with zero undefined ASSYM macros; relinked final binary (fix_run.log, final_binary_fixed.txt): 0 U GD_*, 18 exports*, link exit 0. Every restored value matches the independent TU checker exactly, e.g. gd_currentldt=0x3f14 — struct-consistent (gd_spending 0x3f0c + gd_sdelayed 0x3f10 + int → 0x3f14, globaldata.h:74-78).

Contract-wide cross-checks (pass-2 checklist)

• (b) offset-vs-struct correctness: offset_check.c re-evaluates every one of the 44 emitted ASSYM expressions in a separate TU compiled with the exact genassym CFLAGS — 44/44 values match assym.s (only the 0x presentation differs). No stale offsets. Negative result, with evidence.
• (c) used-vs-defined inventory: every CAPS macro token extracted from all 4 platform .s consumers + 3 cpu/x86_64/misc .s consumers; the ONLY unmatched set is the 21 GD_* in global.s. swtch.s's MSR_FSBASE/MSR_KGSBASE uses are inside #if 0 and additionally resolvable from specialreg.h (swtch.s includes / chains).
• (d) vkernel-specific fields: TD_SAVEFPU=0x628 verified == offsetof(struct thread, td_mach.mtd_savefpu) (thread.h:43,49), consumed live by swtch.s:558,701 — correct. The DF-5655 TLS-aliasing chain (td_tls == td_mach.mtd_savevext.vx_tls, thread.h:50) is C-side only: CHECK_td_tls=CHECK_mtd_savevext=0x630, CHECK_vx_tls=0, and NO assembly consumer references it (swtch.s's TLS-restore block at :477-484 is #if 0). No genassym exposure — negative result, chain documented.
• DF-5597 twin (ioapic stride): zero IOAPIC_* tokens in any vkernel64 .s consumer — not applicable on this platform.

Incidental discovery (out-of-file lead, task_log'd)

The full VKERNEL64 build fails at link on kern_mib.c:111/132 → undefined reference to '__build_id_start/__build_id_end' (vkbuild.log): kern.pre.mk's default SYSTEM_LD passes -Wl,-T,$S/platform/$P/conf/ldscript.$M (which PROVIDEs both symbols, vkernel64/conf/ldscript.x86_64:75), but vkernel64's conf/Makefile SYSTEM_LD override drops -T, so the vkernel64 kernel has been unbuildable since the build-id sysctl landed. This failure is also what empirically delimits the DF-5596 mechanism on the vkernel link: the link DOES fail hard on relocation-referenced undefined symbols (__build_id_ has relocations) while tolerating the 21 zero-relocation GD_ dangles silently.

Why it matters / impact ceiling

• Today: zero runtime effect — nothing references the vanished symbols by relocation; C code uses mdcpu-> (and vkernel64's set_user_ldt panics, userldt.c:44 — no LDT support). The .globl exports that ddb/kgdb scripts and future assembly would rely on simply do not exist, on the platform whose debugger (in-process ddb) reads the vkernel's own symtab.
• Systemically: the genassym contract is the ONLY build-time guard for the C↔asm offset agreement (the silent memory-corruption class this audit family tracks — DF-5586/5335 lineage). This file shows the guard failing silently 21 ways at once on the platform with the weakest link gate, and 8 of the 21 cannot even be "restored" (fields absent) — a maintainer attempting the obvious fix hits a compile error and is likely to abandon all 21.

Classification

Reproduced: yes — object level (nm global.o), final-binary level (21 U, 0 relocations, link exit 0), and controlled fix (0 U, 18 exports, values independent-TU verified). Exploit chain: none — build-time contract defect, no attacker-reachable primitive. Recommended fix validated: fix.diff (git-apply-clean against pristine sys/, never applied to the audit tree).

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.