> 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 rgri...@freebsd.org _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
