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

[Warner Losh]

On Tue, Apr 16, 2019, 4:51 PM Rodney W. Grimes <freebsd at gndrsh.dnsmgr.net>
wrote:

> > 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.
>
> Isnt this also the case for bhyveload?  We do not go through the loader
> there when we are starting a FreeBSD guest, correct?
>

Bhyveload is a copy of the boot loader and runs userboot to make it happen.

Warner

> John Baldwin
> --
> Rod Grimes
> rgrimes at freebsd.org
>
>