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

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

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

Best,
Conrad