svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys
Rodney W. Grimes
freebsd at gndrsh.dnsmgr.net
Tue Apr 16 22:51:04 UTC 2019
> 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?
> John Baldwin
--
Rod Grimes rgrimes at freebsd.org
More information about the svn-src-all
mailing list