DF-0220 / leak_sample.txt
================================================================================
DF-0220 — Cross-boot RNG keystream comparison (the decisive reproducibility test)
================================================================================
Re-verified: 2026-07-03 on DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC
2026 (unpatched audit-source kernel).
The finding claims: "/dev/urandom + getrandom + kern.random return a deterministic
ChaCha20 keystream (zero key) before first reseed — byte-for-byte reproducible
sequence identical on every booted machine."
Test method: vm.sh reset with-src to a pristine snapshot, boot, read 64 bytes
from every RNG interface as soon as ssh comes up. Repeat on 2 more fresh boots
(3 boots total). Compare byte-for-byte. Also compare against the reference
"pre-reseed degenerate" keystream computed by ref_keystream.c.
--------------------------------------------------------------------------------
REFERENCE: the degenerate pre-reseed csprng keystream (ref_keystream.c output)
--------------------------------------------------------------------------------
This is what /dev/urandom WOULD return (csprng-only, rand_mode=0) if reseed had
not happened. It is computed by running the kernel's exact chacha20
(CHACHA_NONCE0_CTR128 + KEYSTREAM_ONLY) on the all-zero cipher context that
csprng_init() leaves when chacha_keysetup() is never called. NOTE: all-zero
input is a FIXED POINT of the chacha quarterround (0+0=0, 0^0=0, rotl(0,n)=0),
so the "keystream" is all zeros.
ref_preseed_keystream (64 bytes, all-zero chacha input[16]):
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
(The finding described this as "ChaCha20(key=0^32, counter=0^16)" — that is
inaccurate: with keysetup never called, input[0..3] (the sigma constants)
are ALSO zero, so the real degenerate output is all-zeros, not standard
zero-key chacha20 which would be non-zero.)
--------------------------------------------------------------------------------
BOOT #1 (fresh vm.sh reset with-src; uptime at read = 82.94 s; rand_mode=mixed)
--------------------------------------------------------------------------------
/dev/urandom (64 bytes):
0000: 51 6a e3 97 93 d1 1d 12 a2 54 86 b1 80 c5 96 de
0010: 4c 73 e3 25 e4 7d d9 98 67 bc 16 05 0f 93 3f e8
0020: 45 33 4a c8 15 50 18 27 b6 ef f0 0b 18 b6 4a 73
0030: b7 b6 d4 db c3 e6 b9 15 a3 5c 67 70 df d2 9f 4a
getrandom(2) (64 bytes):
0000: c5 63 d1 3a 35 19 2a cc e0 b2 a9 62 b4 ea 61 e2
0010: af 91 c3 99 ef 66 2f dc a5 45 67 77 fe 39 2c 4f
0020: 9c c2 b2 1c 5e 77 39 df 83 de ab 6d 8b f9 85 1e
0030: 26 fb 1c 75 fe 0e bb 4a 5c b9 1d 41 af 0d 2b 0d
kern.random sysctl (64 bytes):
0000: 41 92 b2 78 b4 92 f9 c6 6b 59 c6 46 3f 8e fa c0
0010: dd 42 f0 f9 8f 3f 8f de af 38 10 25 e9 d0 42 cb
0020: ed 5b 1b c4 14 e5 5f 7f 3a 9d fb cf 5e d7 0b b0
0030: 71 ad be 27 0c 0d 5c c9 1a aa c6 28 05 4d ec b3
--------------------------------------------------------------------------------
BOOT #2 (fresh vm.sh reset with-src; uptime at read = 28.38 s; rand_mode=mixed)
--------------------------------------------------------------------------------
/dev/urandom (64 bytes):
0000: cc 5d 92 1b d8 d3 4f 06 8b e9 39 81 3d 10 7f 9b
0010: 6b b6 ce d8 6e e7 75 b8 63 ad 14 23 ce 16 43 cb
0020: 73 ae ce f5 8b 8c 99 fa d9 c4 d2 bd 4a 97 5a 1c
0030: 02 08 05 ae 33 1d 4b 38 25 35 5e 34 ec 5d 0e 34
getrandom(2) (64 bytes):
0000: 67 91 41 2b 9e ba 5d 56 2a af c0 0c 5c e2 da 54
0010: a2 76 0f 44 41 2f f6 fc 6d 94 01 da 50 e2 44 b0
0020: 37 02 24 09 c5 af 89 4c be 87 1f 8f e9 63 a9 72
0030: 40 84 16 90 fc 2f 42 b2 67 12 eb 9e ac 4c f0 ea
kern.random sysctl (64 bytes):
0000: f5 28 2f bb f7 52 91 39 ad e7 1a 78 e0 13 2d a9
0010: c3 57 19 86 73 75 05 91 99 33 76 70 f3 d6 1a 9a
0020: 22 61 26 59 ad 4f d8 29 da 96 0b d1 12 a9 9c c4
0030: 7d c5 d3 b6 4b bb dd 21 01 b5 c6 b2 10 5e d8 45
--------------------------------------------------------------------------------
BOOT #3 (fresh vm.sh reset with-src; uptime at read = 22.26 s; rand_mode=mixed)
--------------------------------------------------------------------------------
/dev/urandom (64 bytes):
0000: ee b5 51 40 fb 2e ea 83 84 57 dd 9e 73 80 7c 48
0010: be bc 5e c6 01 e4 fe 61 af 44 1d ab 49 3d dd 85
0020: 6f 85 d2 57 97 2d 44 f6 05 29 31 eb b9 ab de f8
0030: 9c 0d 43 33 2a 95 72 33 7b ed 39 d3 62 00 6f e6
getrandom(2) (64 bytes):
0000: a8 93 ed 33 65 fd 92 c7 66 e3 f5 99 9e 2d 04 f5
0010: e7 9f a3 0c 08 cb 76 7d 67 15 36 ea a1 15 b3 1a
0020: 5b 96 a9 08 a4 e0 21 6b f7 89 12 b7 b4 c8 1f 6b
0030: f6 50 e6 36 4b d0 24 3d 8f 91 03 63 b6 8b 13 46
kern.random sysctl (64 bytes):
0000: 48 be ed 35 4f ae 39 89 0b ac f3 e0 7d a0 e6 be
0010: e4 9a 9c 17 a1 24 44 fb 5c af 65 ef 89 a3 08 d1
0020: d8 51 6c fa 22 fb 63 80 bb f8 22 87 6c 92 cb cb
0030: 48 5d a8 fb 8c 70 68 99 40 04 ff e5 fe 22 32 0c
--------------------------------------------------------------------------------
COMPARISON RESULT (3 independent fresh boots)
--------------------------------------------------------------------------------
Boot #1 /dev/urandom vs Boot #2 /dev/urandom : 64/64 bytes differ (0 match)
Boot #1 /dev/urandom vs Boot #3 /dev/urandom : 64/64 bytes differ (0 match)
Boot #2 /dev/urandom vs Boot #3 /dev/urandom : 64/64 bytes differ (0 match)
Boot #1 getrandom vs Boot #2 getrandom : 64/64 bytes differ (0 match)
Boot #1 getrandom vs Boot #3 getrandom : 64/64 bytes differ (0 match)
Boot #2 getrandom vs Boot #3 getrandom : 64/64 bytes differ (0 match)
Boot #1 kern.random vs Boot #2 kern.random : 64/64 bytes differ (0 match)
Boot #1 kern.random vs Boot #3 kern.random : 64/64 bytes differ (0 match)
Boot #2 kern.random vs Boot #3 kern.random : 64/64 bytes differ (0 match)
Any boot vs reference (all-zero) : 64/64 bytes differ (0 match)
=> The kernel RNG output is NOT deterministic across boots on this kernel, and
it NEVER matches the degenerate all-zero pre-reseed keystream. The finding's
reproducibility claim is REFUTED on DragonFly master DEV (6.5-DEVELOPMENT #0,
Thu Jul 2 06:02:54 UTC 2026).
--------------------------------------------------------------------------------
DECISIVE SECONDARY TEST: csprng-only mode (rand_mode=csprng) is non-zero
--------------------------------------------------------------------------------
If reseed had NOT happened before userspace, rand_mode=csprng (which returns
the raw csprng stream with no IBAA mixing) would emit the all-zero fixed-point
keystream above. Three consecutive reads (16 B each) with rand_mode=csprng on a
live boot:
run1: 8c a6 62 2b ac cc c6 9b cc cc c6 60 e5 08 fb ac
run2: 92 ff 5c d9 bb e7 0e f0 a6 4a 75 d3 00 71 11 1e
run3: 7e 77 de 53 8a 23 0e c7 94 a7 ac 67 e0 b1 70 55
All non-zero, all distinct -> the csprng cipher context is properly keyed
(i.e. csprng_reseed() has run) BEFORE any userspace read reaches it.
================================================================================
ROOT CAUSE OF NON-REPRODUCTION (line-by-line trace in sys/)
================================================================================
rand_initialize() (sys/kern/kern_nrandom.c:485-560) is a SYSINIT registered
at SI_BOOT2_POST_SMP=0x1cc0000, SI_ORDER_SECOND (kern_nrandom.c:562).
init(8) is launched at SI_SUB_KTHREAD_INIT=0xe000000 (sys/sys/kernel.h:216),
which is ~200 later in subsystem ordering. rand_initialize therefore runs to
completion BEFORE any userspace program can issue a read.
Inside rand_initialize, for each CPU:
1. csprng_init(state) (kern_nrandom.c:507) -- key=0, ctx=0, reseed_cnt=0
2. timing loop: 128 csprng feeds of 8 B each via RAND_SRC_TIMING (0x02)
(kern_nrandom.c:517-531). csprng_add_entropy routes by
`pool_id = src_pool_idx[src_id & 0xff]++ & 0x1f` (subr_csprng.c:272-273);
src_pool_idx[0x02] cycles 0..31, so each pool gets ~4 feeds (~32 B in
pool[0]). This is the ONLY entropy the finding considered, and on that
basis alone its "pool[0] < 96 bytes" claim would hold.
3. **THE FEED THE FINDING OMITS** (kern_nrandom.c:539-543):
state->inject_counter[RAND_SRC_THREAD2] = 0;
add_buffer_randomness_state(state, (void *)rgd, sizeof(*rgd),
RAND_SRC_THREAD2);
RAND_SRC_THREAD2 = 0x0c (sys/sys/random.h:89). inject_counter[0x0c] starts
at 0, so ++ makes it 1 -> `ic & 1` branch in add_buffer_randomness_state
(kern_nrandom.c:614) calls csprng_add_entropy(state, 0x0c & RAND_SRC_MASK, ...).
src_pool_idx[0x0c] starts at 0 -> pool_id = 0. So sizeof(struct globaldata)
lands ENTIRELY in pool[0]. DWARF + gdb confirm sizeof(struct globaldata) =
14976 bytes on this build (gd_reserved02B[200] alone is 1600 B; plus
gd_idlethread, gd_slab, gd_kmslab, gd_systimerq, gd_systimer x3, etc.).
pool[0] therefore receives 32 (timing) + 14976 (rgd) = ~15008 bytes, far
beyond MIN_POOL_SIZE = 96 (sys/kern/subr_csprng.c:54,188).
4. read_random(buf, sizeof(buf), 1) (kern_nrandom.c:558) -> csprng_get_random
-> ratecheck() fires on first call (subr_csprng.c:134-135) -> csprng_reseed
(subr_csprng.c:176). The guard `state->pool[0].bytes < MIN_POOL_SIZE`
(subr_csprng.c:188) PASSES -> reseed_cnt becomes 1 (subr_csprng.c:201),
a fresh key is derived from the pools via SHA-256 (subr_csprng.c:228),
chacha_keysetup + chacha_ivsetup finally key the cipher
(subr_csprng.c:231,235).
From this point — still inside the kernel SYSINIT, before init(8) runs — every
subsequent read sees a properly-keyed csprng. There is NO userspace-reachable
pre-reseed window. The finding's premise that "pool[0] commonly receives
< 96 bytes during early boot" omits this per-CPU globaldata feed entirely.
NOTE on the globaldata content: rgd holds live kernel pointers (slab caches,
thread structs, systimer queues, etc.) that vary boot-to-boot due to KASLR,
allocation order, and timing; empirically the resulting csprng key differs
across the 3 boots (above), confirming the input entropy is not constant.
================================================================================
CLASSIFICATION
================================================================================
False-premise / not-reachable-on-this-kernel: the code pattern the finding
describes (CSPRNG_UNLIMITED bypasses the reseed_cnt==0 gate; cipher is never
keyed at init; all-zero chacha state is a fixed point) is REAL and is a
legitimate defense-in-depth gap. But the userspace-observable pre-reseed window
the threat model relies on does not exist on master DEV because the per-CPU
globaldata entropy feed (kern_nrandom.c:539-543) closes it during rand_initialize
(kernel SYSINIT SI_BOOT2_POST_SMP), before init. The cross-boot determinism the
finding predicts is empirically absent across 3 independent fresh boots.
fix.diff provides targeted defense-in-depth hardening (gate unlimited readers
too, return 0 instead of emitting the degenerate keystream) but is NOT a fix
for a reproduced vuln; Phase 8 single-fix-kernel build/boot is therefore not
applicable (the patched kernel would behave identically to the unpatched one,
since reseed_cnt is already >0 before any userspace read).