⬢ DragonFlyBSD Kernel Audit
DF-0220 / env.txt
← back to finding ↓ download raw
================================================================================
DF-0220 verification environment (re-verified 2026-10-12, VERIFY mode)
================================================================================
Guest: DragonFlyBSD master DEV (KVM, single-tenant, vm.sh-managed)
Snapshot reverted between boots via: dfbsd-qemu/vm.sh reset with-src

uname -a:
  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

Workspace tree == guest /usr/src (both pristine):
  md5(sys/kern/subr_csprng.c) = c115d52f222269d185da27510e0beb89
  last commit touching subr_csprng.c/kern_nrandom.c: 2026-06-27 (pre-dates the
  July verification runs; source IDENTICAL for both).

cc --version:
  cc 8.3 [DragonFly] Release/2019-02-22

QEMU/KVM (vm.sh): qemu-system-x86_64 -enable-kvm -m 4096 -smp 6,
  virtio-blk + user-mode net (hostfwd 127.0.0.1:5522-:22)
  NO virtio-rng device; guest CPU exposes no RDRAND:
  dmesg: "rdrand0: No RdRand support."  -> entropy-poor virtual machine:
  exactly the environment in which the finding predicted an indefinite
  deterministic window.

sysctl after boot:
  kern.rand_mode: mixed    (default: rand_mode==2 -> csprng XOR IBAA)
  hw.ncpu: 6

Kernel symbols (nm /boot/kernel/kernel):
  ffffffff81199140 b csprng_pcpu
  ffffffff81197740 b csprng_boot
  ffffffff811976f8 b rand_td

Per-CPU csprng_state layout (kernel.debug DWARF, same as DF-5766 rig):
  key@0 (32 B), reseed_cnt@32, cipher_ctx@40 (64 B = chacha input[16]),
  pool[0].bytes@104 (pool stride 112), nrandevents@4240,
  last_reseed@4256, sizeof(struct csprng_state) = 6656 (0x1a00)
  Live-verified this run: bytes 40..55 of a healthy state contain the chacha
  sigma constants "expand 32-byte k" (see kmem_window_decisive.log [peekctx]).

usched(1) semantics (matters for per-CPU pinning):
  usage: usched [-d] {scheduler[:cpumask] | :cpumask} program ...
  cpumask format: val[,val...] in 64-bit chunks, lsb chunk first
  => ":1"=cpu0, ":2"=cpu1, ":4"=cpu2, ":3"={cpu0,cpu1}.  (DF-5766's rig used
  ":1" for the BSP -- correct.  ":N" is a MASK, not an index; my first two
  window attempts mis-pinned this way -- see VERDICT.md.)

run notes:
  - No panic occurred at any point (pure read-only + kmem-state experiments).
  - rand_mode was restored to "mixed" and all per-CPU states verified healthy
    (reseed_cnt>=1, sane timestamps) before returning the guest.
  - /usr/src left pristine (md5 c115d52f... verified after fix.diff dry-runs).