DF-0220 — PoC: Predictable RNG pre-reseed claim (verification)

Finding: findings/DF-0220-csprng-predictable-rng-pre-reseed.md Claim: /dev/urandom, getrandom(2), and kern.random return a deterministic all-zero-key ChaCha20 keystream before the first Fortuna reseed — identical across independent boots.

Verdict (re-verified 2026-10-12, VERIFY mode): NOT REPRODUCED. No unprivileged user can observe the pre-reseed window on this kernel — but the emit mechanism itself is now PROVEN live and fully deterministic via a root-manufactured state (/dev/urandom returns literal 0x00 bytes, then a keystream reproduced offline by chain_model.py, 5/5 identical trials). See VERDICT.md for the full line-cited trace and the DF-5766 overlap.

Files

Build

./build.sh                 # rand_probe + ref_keystream
cc -O2 -o zero_scan zero_scan.c
cc -O2 -o csprng_force_zero csprng_force_zero   # root tool

Run

./run.sh                          # single-boot probe (unprivileged)
./boot_probe.sh                   # full fresh-boot probe (root; su's down to maxx)
usched :4 ./csprng_force_zero <sym> window 2   # manufactured window (root, csprng mode)
python3 chain_model.py            # offline model -> matches the above

(sym = nm /boot/kernel/kernel | awk '/ csprng_pcpu$/ {print "0x"$1}')

Expected (claim TRUE / bug present)

Across independent fresh boots the 64-byte outputs would be byte-for-byte identical AND identical to the degenerate reference; zero_scan would see all-zero blocks; rand_mode=csprng would return 0x00 bytes.

Actual (DragonFly 6.5-DEVELOPMENT #0, 2026-10-12)

Three fresh vm.sh reset with-src boots: outputs differ 59-60/64 bytes on every interface and every boot pair, never all-zero; 0/6624 all-zero blocks in the first 33 s of boot; every per-CPU state already keyed (reseed_cnt>=1) at the earliest ssh. The window CAN be manufactured with root /dev/kmem — and then behaves exactly as the finding predicted (deterministic 0x00… chain) — but the precondition (reseed_cnt==0 ∧ pool[0]<96 at an UNLIMITED read) is unreachable from userspace because rand_initialize() pre-feeds every state's pool[0] with ~15 KB before its first possible read, and the reseed attempt precedes the emit loop. See VERDICT.md.

Reproduce across boots (the decisive test)

for N in 1 2 3; do
  dfbsd-qemu/vm.sh reset with-src
  scp -F dfbsd-qemu/config {rand_probe,ref_keystream,zero_scan,csprng_force_zero}.c boot_probe.sh dfbsd:/tmp/rng220/
  dfbsd-qemu/vm.sh run_root 'sh /tmp/rng220/boot_probe.sh' > boot${N}_probe.txt
done
# then compare the hex sections (see leak_sample.txt) — they must differ

DF-0220 VERDICT -- not_reproduced (impact: none; confidence: certain)

Bottom line

NOT REPRODUCED (3rd verification, 2026-10-12, source unchanged since 2026-06-27). No unprivileged user can observe the pre-reseed zero-key window on this kernel: rand_initialize() (kern_nrandom.c:485-560, SYSINIT SI_BOOT2_POST_SMP :562, before init(8)) pre-feeds EVERY per-CPU state's pool[0] with ~15 KB (sizeof(struct globaldata)=14976 B via RAND_SRC_THREAD2 :539-543), and csprng_get_random() always attempts a reseed BEFORE its emit loop (subr_csprng.c:134-149 precede :151-166) with ratecheck's {0,0} first-call guarantee (kern_time.c:1153-1157) -- so each state's first read keys the cipher before emitting a byte. Live proof: on 3 fresh boots every state shows reseed_cnt>=1/key!=0 at the earliest ssh (uptime 17-33 s); the BSP is frozen at reseed_cnt=1 with last_reseed=184467440735.6xxxxx (the garbage getmicrouptime captured AT its rand_initialize-time reseed, = DF-5766's frozen baseline -- pinning the first reseed pre-userland). Cross-boot outputs differ 59-60/64 bytes on all interfaces/pairs; 0 all-zero blocks in 6624 unprivileged early-boot samples (urandom+getrandom+kern.random); default mixed mode additionally XORs IBAA (kern_nrandom.c:708-713), masking even a manufactured window. NEW this pass: the mechanism itself is now PROVEN live and fully deterministic -- with a root /dev/kmem-manufactured state (reseed_cnt=0 AND key=0 AND ctx=0 AND pool[0].bytes=0 AND last_reseed={0,0}), /dev/urandom in rand_mode=csprng returns literal 0x00*32 and then a keystream chain_model.py reproduces offline exactly (4/4 blocks + 4/4 internally-loaded keys, 5/5 byte-identical trials; per-read live ctx dumps match). The manufactured window is consumed by the first background reader within ~0.2 s and self-heals via reseed within seconds of pool[0] refilling -- it is unreachable and unstable, never userspace-observable. Overlap with DF-5766: DF-5766's frozen-BSP bug is what makes the BSP's reseed_cnt permanently 1 (never 0), reinforcing closure; the entropy quality of the BSP's single forever-key is DF-5766's subject, not DF-0220's zero-key window.

Reproduce

build: cc -O2 -o rand_probe rand_probe.c && cc -O2 -o ref_keystream ref_keystream.c && cc -O2 -o zero_scan zero_scan.c && cc -O2 -o csprng_force_zero csprng_force_zero.c
run:   sh boot_probe.sh (per fresh vm.sh reset with-src boot, 3x); SYM=0x$(nm /boot/kernel/kernel | awk '/ csprng_pcpu$/ {print $1}'); sysctl kern.rand_mode=csprng; usched :4 ./csprng_force_zero $SYM window 2 (x5); python3 chain_model.py

Evidence in this pack

kmem_window_decisive.log (THE decisive run: sigma-at-offset-40 proof; 5/5 identical manufactured windows with blk1=0x00*32; mixed-mode non-zero; self-heal pool0 0->372 -> reseed_cnt 1); kmem_window_chain.log + chain_model.py (per-read live ctx dumps equal the offline model 4/4 blocks + 4/4 keys 523b05d3/4b57cfe4/8b5a7c87/22589bb5); boot{1,2,3}_probe.txt (fresh boots: unprivileged 4-source reads + zero_scan 0/6624 zero blocks + all 6 states keyed at earliest ssh, BSP frozen at reseed_cnt=1 with 184467440735.6xx); leak_sample.txt (cross-boot pairwise 59-60/64 differ, never all-zero); final_verify.txt (full sequence); fix_apply_compile.log (applies @138 + compiles with exact kernel CFLAGS); env.txt; VERDICT.md

Kernel references

• sys/kern/subr_csprng.c:84
• sys/kern/subr_csprng.c:85
• sys/kern/subr_csprng.c:134
• sys/kern/subr_csprng.c:137
• sys/kern/subr_csprng.c:146
• sys/kern/subr_csprng.c:151
• sys/kern/subr_csprng.c:155
• sys/kern/subr_csprng.c:158
• sys/kern/subr_csprng.c:176
• sys/kern/subr_csprng.c:188
• sys/kern/subr_csprng.c:231
• sys/kern/subr_csprng.c:272
• sys/kern/kern_nrandom.c:485
• sys/kern/kern_nrandom.c:495
• sys/kern/kern_nrandom.c:539
• sys/kern/kern_nrandom.c:543
• sys/kern/kern_nrandom.c:558
• sys/kern/kern_nrandom.c:562
• sys/kern/kern_nrandom.c:697
• sys/kern/kern_nrandom.c:708
• sys/kern/kern_nrandom.c:739
• sys/kern/kern_nrandom.c:770
• sys/kern/kern_time.c:1153
• sys/kern/kern_memio.c:352
• sys/platform/pc64/x86_64/machdep.c:2777
• sys/sys/kernel.h:168
• sys/sys/kernel.h:216
• sys/crypto/chacha20/chacha.c:56

Fix validation (A/B)

Defense-in-depth only (window already closed by the rgd pool-pre-feed): fix.diff gates CSPRNG_UNLIMITED readers too when reseed_cnt==0, returning 0 bytes instead of emitting the degenerate keystream (mirrors getrandom(GRND_NONBLOCK)); applies cleanly (hunk @138) and compiles warning-free with exact kernel CFLAGS (fix_apply_compile.log).

Baseline vs post-fix behavior is in run.log / run_fixed*.log (userspace) or panic.txt/hang.txt vs run_fixed_kernel.log (kernel); the identical rig ran both sides.

poc_changes

Added csprng_force_zero.c (root /dev/kmem rig: info/force/check/restore/peekctx/window/window2 -- force manufactures the exact precondition tuple reseed_cnt=0 ^ key=0 ^ ctx=0 ^ pool0.bytes=0 ^ last_reseed={0,0}), zero_scan.c (unprivileged 3-interface window scanner; fixed missing sys/random.h include flagged by guest cc), chain_model.py (offline model of the degenerate emit chain, validated 4/4 blocks + 4/4 keys vs live ctx dumps), boot_probe.sh + window_experiment{,2}.sh drivers, and 6 new evidence logs. ref_keystream.c gained a zerokey mode (validated against the RFC 7539 zero-key vector 76b8e0ad...). rand_probe.c unchanged. Key rig lesson: usched :N is a CPU MASK (:4=cpu2), not an index -- attempts 1-2 mis-pinned; and a separate-process read loses the manufactured window to a background consumer within ~0.2 s, so the window action forces+reads in-process.

Guest: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64 Attempts: 8 Runtime: ~2400s

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.