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

[Conrad Meyer]

On Tue, Apr 16, 2019 at 4:28 PM John Baldwin <jhb at freebsd.org> wrote:
> Yes, but we need some kind of non-blocking API, not an unconditionally-blocking API
> that deadlocks.

I'm not sure we do.  It would be sufficient to check once at subsystem
initialization time.  There's no race condition such that we block
again once we're seeded.

As far as APIs go, read_random_uio is nonblocking, although not an
arc4random interface (and quite cumbersome to set up and use).

> 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?

No, that's incorrect.  We periodically pull new Fortuna (devrandom)
output to reseed chacha20 in arc4random, but once Fortuna is "seeded,"
it *never* blocks ever again.

> Or maybe arc4random passes in a flag to disable
> reseeding so it isn't blocking once the PRNG has been seeded at least once?

As above, *re*seeding arc4random never blocks.

> 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.

I think the alternative EWOULDBLOCK proposal is worse than
WITNESS_WARN.  But I highlighted some problems with WITNESS_WARN in my
earlier email; how would you resolve them?

> Code that trips over the warning would have to be changed to use the non-blocking
> API and then deal with EWOULDBLOCK.

Or it could just check that the random device is seeded, prior to
using arc4random?

> 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.

That's more or less the status quo with no-error arc4random, no?

> There are things like virtio-rng for modern x86 VM environments, but those don't
> exist on things like the MIPS MALTA machine.

They probably probe later than SI_SUB_RANDOM too :-(.

> 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.

Sure.  It would probably be ok to have a knob for that.  We would want
to be careful about naming it / documenting it; the thing about knobs
is people tend to twiddle them.

Best,
Conrad