K 10
svn:author
V 6
obrien
K 8
svn:date
V 27
2022-02-13T07:30:44.321126Z
K 7
svn:log
V 2465
Fortuna: Fix false negatives in is_random_seeded()

(1) We may have had sufficient entropy to consider Fortuna seeded, but the
random_fortuna_seeded() function would produce a false negative if
fs_counter was still zero.  This condition could arise after
random_harvestq_prime() processed the /boot/entropy file and before any
read-type operation invoked "pre_read()."  Fortuna's fs_counter variable is
only incremented (if certain conditions are met) by reseeding, which is
invoked by random_fortuna_pre_read().

is_random_seeded(9) was introduced in r346282, but the function was unused
prior to r346358, which introduced this regression.  The regression broke
initial seeding of arc4random(9) and broke periodic reseeding[A], until something
other than arc4random(9) invoked read_random(9) or read_random_uio(9) directly.
(Such as userspace getrandom(2) or read(2) of /dev/random.  By default,
/etc/rc.d/random does this during multiuser start-up.)

(2) The conditions under which Fortuna will reseed (including initial seeding)
are: (a) sufficient "entropy" (by sheer byte count; default 64) is collected
in the zeroth pool (of 32 pools), and (b) it has been at least 100ms since
the last reseed (to prevent trivial DoS; part of FS&K design).  Prior to
this revision, initial seeding might have been prevented if the reseed
function was invoked during the first 100ms of boot.

This revision addresses both of these issues.  If random_fortuna_seeded()
observes a zero fs_counter, it invokes random_fortuna_pre_read() and checks
again.  This addresses the problem where entropy actually was sufficient,
but nothing had attempted a read -> pre_read yet.

The second change is to disable the 100ms reseed guard when Fortuna has
never been seeded yet (fs_lasttime == 0).  The guard is intended to prevent
gratuitous subsequent reseeds, not initial seeding!

Machines running CURRENT between r346358 and this revision are encouraged to
refresh when possible.  Keys generated by userspace with /dev/random or
getrandom(9) during this timeframe are safe, but any long-term session keys
generated by kernel arc4random consumers are potentially suspect.

[A]: Broken in the sense that is_random_seeded(9) false negatives would cause
arc4random(9) to (re-)seed with weak entropy (SHA256(cyclecount ||
FreeBSD_version)).

(cherry picked from commit e8e1f0b4204dc766c4c5af5f259af11f9b0e0452)

Git Hash:   856230b94a544161dbb71406471bf15d48473cfd
Git Author: cem@FreeBSD.org
END