Date: Wed, 17 Apr 2019 11:08:24 -0600 From: Warner Losh <imp@bsdimp.com> To: "Rodney W. Grimes" <rgrimes@freebsd.org> Cc: John Baldwin <jhb@freebsd.org>, "Conrad E. Meyer" <cem@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys Message-ID: <CANCZdfoN33JRWyDK5hLauX%2BW_E%2BsoFiuXN3Gq_txf7Y8oqZFBQ@mail.gmail.com> In-Reply-To: <201904162251.x3GMp2aF097103@gndrsh.dnsmgr.net> References: <457a2c63-f062-8fc6-15d4-6f5b93981930@FreeBSD.org> <201904162251.x3GMp2aF097103@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 16, 2019, 4:51 PM Rodney W. Grimes <freebsd@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@freebsd.org > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoN33JRWyDK5hLauX%2BW_E%2BsoFiuXN3Gq_txf7Y8oqZFBQ>