svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys

[John Baldwin]

On 4/15/19 11:40 AM, Conrad Meyer wrote:
> Author: cem
> Date: Mon Apr 15 18:40:36 2019
> New Revision: 346250
> URL: https://svnweb.freebsd.org/changeset/base/346250
> 
> Log:
>   random(4): Block read_random(9) on initial seeding
>   
>   read_random() is/was used, mostly without error checking, in a lot of
>   very sensitive places in the kernel -- including seeding the widely used
>   arc4random(9).
>   
>   Most uses, especially arc4random(9), should block until the device is seeded
>   rather than proceeding with a bogus or empty seed.  I did not spy any
>   obvious kernel consumers where blocking would be inappropriate (in the
>   sense that lack of entropy would be ok -- I did not investigate locking
>   angle thoroughly).  In many instances, arc4random_buf(9) or that family
>   of APIs would be more appropriate anyway; that work was done in r345865.

There are definitely places arc4random is used where sleeping is not allowed.
ipsec generating nonces for AES-CBC is one example I can think of off the
top of my head.  I think it might be useful to add an explicit WITNESS_WARN
in arc4random to catch these cases so they can be found and reasoned about.

>   This change primarily impacts the behavior of /dev/random on embedded
>   systems with read-only media that do not configure "nodevice random".  We
>   toggle the default from 'charge on blindly with no entropy' to 'block
>   indefinitely.'  This default is safer, but may cause frustration.  Embedded
>   system designers using FreeBSD have several options.  The most obvious is to
>   plan to have a small writable NVRAM or NAND to persist entropy, like larger
>   systems.  Early entropy can be fed from any loader, or by writing directly
>   to /dev/random during boot.  Some embedded SoCs now provide a fast hardware
>   entropy source; this would also work for quickly seeding Fortuna.  A 3rd
>   option would be creating an embedded-specific, more simplistic random
>   module, like that designed by DJB in [1] (this design still requires a small
>   rewritable media for forward secrecy).  Finally, the least preferred option
>   might be "nodevice random", although I plan to remove this in a subsequent
>   revision.

Note that I actually often run into unseeded systems when doing development
using qemu for non-x86 architectures.  For example, when booting mips from
qemu, there is no loader, the kernel just starts, and since the endian is
opposite, I frequently regenerate the filesystem using makefs.

-- 
John Baldwin