Date: Tue, 03 Sep 2019 14:07:51 -0000 From: John Baldwin <jhb@FreeBSD.org> To: cem@freebsd.org Cc: src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <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: <5d790a56-1498-094e-6bb4-48345a231e55@FreeBSD.org> In-Reply-To: <CAG6CVpWu3eaCqe2cYS8FdAna30q58UT3KTiYHjxfv7Yo052dDg@mail.gmail.com> References: <201904151840.x3FIeaEQ009242@repo.freebsd.org> <457a2c63-f062-8fc6-15d4-6f5b93981930@FreeBSD.org> <CAG6CVpWu3eaCqe2cYS8FdAna30q58UT3KTiYHjxfv7Yo052dDg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/16/19 3:49 PM, Conrad Meyer wrote: > On Tue, Apr 16, 2019 at 2:32 PM John Baldwin <jhb@freebsd.org> wrote: >> There are definitely places arc4random is used where sleeping is not allowed. > > Sure. > >> ipsec generating nonces for AES-CBC is one example I can think of off the >> top of my head. > > IVs for AES-CBC are also a great example of a case we should be seeded for. Yes, but we need some kind of non-blocking API, not an unconditionally-blocking API that deadlocks. >> 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. > > Well, we kind of want that, but we also want the warning to disappear > if the consumer has correctly reasoned about it. E.g., if the thread > has verified seeded status with is_random_seeded(), it is no longer > possible for a arc4random consumption to block. Right? I think that > may be difficult to integrate with the WITNESS_WARN, so even if all > consumers are correctly implemented, we will not eliminate the witness > warnings. Do you have any ideas? The only dumb proposal I have is > burning a flag in td_flags for "this thread checked > is_random_seeded(), and it returned true." Eh, I thought that we periodically pulled in new entropy to generate a new chacha20 key for the PRNG and that could be blocking as well when I was last reading this code, or is that not correct? Or maybe arc4random passes in a flag to disable reseeding so it isn't blocking once the PRNG has been seeded at least once? Still, what I would suggest is to have the existing arc4random() use WITNESS_WARN. We could provide an alternative API that is non-blocking and returns EWOULDBLOCK. Code that trips over the warning would have to be changed to use the non-blocking API and then deal with EWOULDBLOCK. One way of dealing with that would be to check the is_random_seeded() flag earlier in the function, subsystem, whatever and then the code could assert that the non-blocking API never failed. >> 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. > > Right. Perhaps we could incorporate boot/entropy generation into > makefs? Or pass host entropy into some kernel accessible region (env > var, whatever) via qemu? The latter is sort of a general problem for > VMs. You want to be able to snapshot and clone a VM without producing > reproducible RNG state, but Fortuna doesn't handle that explicitly > (aside from future entropy differences and forward secrecy causing > quick divergence). There are things like virtio-rng for modern x86 VM environments, but those don't exist on things like the MIPS MALTA machine. I also don't actually care at all (as in absolutely zero) about the entropy of keys generated for a test qemu instance I fire up on my desktop that doesn't permit inbound access from the outside world. Having some kind of tunable / kernel option for those use cases (that isn't the default) doesn't seem unreasonable. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5d790a56-1498-094e-6bb4-48345a231e55>