As reported on -fs@ and -current@ by lev@, mdmfs(8) -> newfs(8) was aborting
due to arc4random(3) sanity check failure when a diskless FreeBSD system
transitioned from unseeded to seeded randomdev state.
Context: userspace arc4random(3), now based on the Chacha stream cipher
(thanks delphij@), seeds itself by requesting a small amount of random data
with the getentropy(3) API, a wrapper around getrandom(2). getrandom(2) is
itself a wrapper around READ_RANDOM_UIO(9), the same routine backing read(2)
of the /dev/random device.
The root of the problem observed by lev@ was that the tsleep() in
READ_RANDOM_UIO set error to EWOULDBLOCK and short-circuited the rest of the
operation. This bubbled up to userspace getentropy(3), which perhaps
mistakenly (getentropy(3) is only allowed to return EIO or EFAULT) raised
the error further to arc4random(3), which then suicided the process.
delphij@ spotted a similar bug in READ_RANDOM_UIO's logic to check for
pending signals. This one is perhaps harder to hit on accident because it
requires requesting over 16 MiB from /dev/random or getrandom(2) in a single
read, which is atypical.