svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys

[John Baldwin]

On 4/16/19 3:49 PM, Conrad Meyer wrote:
> On Tue, Apr 16, 2019 at 2:32 PM John Baldwin <jhb at 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