Bug 205800 - random device not loaded; using insecure entropy
Summary: random device not loaded; using insecure entropy
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.2-STABLE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2016-01-02 13:29 UTC by artem
Modified: 2016-02-10 18:47 UTC (History)
3 users (show)

See Also:

dmesg (8.88 KB, text/plain)
2016-01-02 17:29 UTC, artem
no flags Details
dmesg 10.3-PRERELEASE r294558 (9.93 KB, text/plain)
2016-01-22 12:07 UTC, never
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description artem 2016-01-02 13:29:58 UTC
Something early in the kernel loading need random device but it is loader later (just 2 lines below)

Loading log:

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
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2016-01-02 14:38:25 UTC
Please, you need to tell us what hardware you are running on, in particular, the architecture.
Comment 2 artem 2016-01-02 17:29:28 UTC
Created attachment 164964 [details]

This is dmesg from my server.
Comment 3 Marie Helene Kvello-Aune 2016-01-02 20:48:05 UTC
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.
Comment 4 Marie Helene Kvello-Aune 2016-01-03 04:09:20 UTC
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.
Comment 5 never 2016-01-22 12:07:31 UTC
Created attachment 165949 [details]
dmesg 10.3-PRERELEASE r294558

Same situation on 10.3-PRERELEASE r294558.
Comment 6 commit-hook freebsd_committer 2016-02-10 18:30:40 UTC
A commit references this bug:

Author: jhb
Date: Wed Feb 10 18:29:38 UTC 2016
New revision: 295480
URL: https://svnweb.freebsd.org/changeset/base/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.

  PR:		205800
  Reviewed by:	markm, so@
  Approved by:	so
  Approved by:	re (gjb)
  Tested by:	Mark Saad <nonesuch@longcount.org>

Comment 7 John Baldwin freebsd_committer freebsd_triage 2016-02-10 18:47:10 UTC
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.