On 4/16/19 3:49 PM, Conrad Meyer wrote: > On Tue, Apr 16, 2019 at 2:32 PM John Baldwin <j...@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 _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
