Something early in the kernel loading need random device but it is loader later (just 2 lines below)
Jan 1 16:37:41 omni kernel: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
Jan 1 16:37:41 omni kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads
Jan 1 16:37:41 omni kernel: cpu0 (BSP): APIC ID: 0
Jan 1 16:37:41 omni kernel: cpu1 (AP): APIC ID: 1
Jan 1 16:37:41 omni kernel: cpu2 (AP): APIC ID: 2
Jan 1 16:37:41 omni kernel: cpu3 (AP): APIC ID: 3
Jan 1 16:37:41 omni kernel: cpu4 (AP): APIC ID: 4
Jan 1 16:37:41 omni kernel: cpu5 (AP): APIC ID: 5
Jan 1 16:37:41 omni kernel: cpu6 (AP): APIC ID: 6
Jan 1 16:37:41 omni kernel: cpu7 (AP): APIC ID: 7
Jan 1 16:37:41 omni kernel: random device not loaded; using insecure entropy
Jan 1 16:37:41 omni kernel: ioapic0 <Version 2.0> irqs 0-23 on motherboard
Jan 1 16:37:41 omni kernel: random: <Software, Yarrow> initialized
Please, you need to tell us what hardware you are running on, in particular, the architecture.
Created attachment 164964 [details]
This is dmesg from my server.
I'm seeing this as well, on a Xeon D 1520 (http://ark.intel.com/products/87038/Intel-Xeon-Processor-D-1520-6M-Cache-2_20-GHz), supermicro X10SDV-4C-TLN2F mainboard. (http://www.supermicro.nl/products/motherboard/xeon/d/X10SDV-4C-TLN2F.cfm)
(uname -a: FreeBSD saturn 10.2-STABLE FreeBSD 10.2-STABLE #0 r293044: Sat Jan 2 01:35:51 CET 2016 root@saturn:/usr/obj/usr/src/sys/GENERIC amd64)
Not seeing it in FreeBSD 11-CURRENT running in vmware on a Xeon E5-1650v3. (this is using random: fast provider: "Intel Secure Key RNG"
Seeing it on bare metal 10-STABLE running on a Xeon E5-1620v2.
All CPUs support "Secure Key". Will install 11-current on the Xeon D and see if it works as expected then.
I'm writing this update because I said I would, even though I realize now that the dmesg output on 11-CURRENT is irrelevant to this PR due to what looks like substancial changes in the /dev/random subsystem between 10-STABLE and 11-CURRENT, which is not entirely unexpected.
Even though the same message appears on several generations and classes of Intel hardware, it might be useful if someone could check if this happens on AMD hardware as well.
Created attachment 165949 [details]
dmesg 10.3-PRERELEASE r294558
Same situation on 10.3-PRERELEASE r294558.
A commit references this bug:
Date: Wed Feb 10 18:29:38 UTC 2016
New revision: 295480
Adjust initialization of random(9) so it is usable earlier.
A few existing SYSINITs expect the in-kernel PRNG (random(9)) to be
useable at SI_SUB_RANDOM / SI_ORDER_ANY. However, the random(4) overhaul
merged for 10.0 performs all of its initialization at SI_SUB_DRIVERS
(since it is tied in with creating the /dev/random character device).
This has changed in HEAD where the random initialization is split such
that the in-kernel random(9) is initialized at SI_SUB_RANDOM and the
supporting bits for userland random(4) (such as /dev/random) are initialized
However, the changes in HEAD are large and invasive. Instead, this change
is being directly committed to stable/10.
This change moves most of the random(9)/random(4) initialization to
SI_SUB_RANDOM with the exception that the creation of the harvesting kernel
process and the /dev/random character device are deferred to new
SYSINITs that run at SI_SUB_DRIVERS.
This fixes the "random device not loaded; using insecure entropy" message
output during boot on some systems.
Reviewed by: markm, so@
Approved by: so
Approved by: re (gjb)
Tested by: Mark Saad <firstname.lastname@example.org>
I believe the referenced commit should fix this. I do not think there are any plans currently to backport that change to older releases, but it will be included in 10.3.