Page MenuHomeFreeBSD

randomdev: Remove 100 ms sleep from write routine
ClosedPublic

Authored by cperciva on Nov 13 2021, 6:57 PM.
Tags
None
Referenced Files
F99719099: D32984.diff
Sat, Oct 12, 11:32 AM
Unknown Object (File)
Fri, Oct 11, 3:59 AM
Unknown Object (File)
Thu, Oct 10, 1:02 PM
Unknown Object (File)
Tue, Oct 8, 6:58 PM
Unknown Object (File)
Tue, Oct 8, 1:04 AM
Unknown Object (File)
Sat, Oct 5, 10:47 PM
Unknown Object (File)
Sat, Oct 5, 9:56 AM
Unknown Object (File)
Tue, Oct 1, 8:45 PM
Subscribers

Details

Summary

This was introduced in 2014 along with the comment (which has since
been deleted):

/* Introduce an annoying delay to stop swamping */

Modern cryptographic random number generators can ingest arbitrarily
large amounts of non-random (or even maliciously selected) input
without losing their security.

Depending on the number of "boot entropy files" present on the system,
this can speed up the boot process by up to 1 second.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

cperciva created this revision.
cem added a subscriber: cem.

Fortuna doesn't specify the 100ms sleep behavior, as far as I can tell. Removing it seems reasonable to me.

sys/dev/random/randomdev.c
344–346

Is this condition even possible anymore? The only way I can see the accumulation loop exiting early is if we hit trap on an invalid userspace buffer, producing EFAULT. randomdev_accumulate() is incapable of failure.

This revision is now accepted and ready to land.Nov 13 2021, 7:05 PM
sys/dev/random/randomdev.c
344–346

Maybe possible if there's a page fault and a signal arrives while the data is being faulted in? I agree that it's unlikely though.

sys/dev/random/randomdev.c
344–346

If that case does happen, should we squash actually error, rather than returning EINTR? I thought we were supposed to bubble that up to the syscall entry layer, generally.

Anyway, orthogonal to your improvement here. Thanks!

sys/dev/random/randomdev.c
344–346

No, this code is correct -- we return EINTR from the syscall if the write was interrupted before writing anything (i.e. if uio_resid is still equal to nbytes), but if at least one byte was written then write(2) returns success with a short write length.

sys/dev/random/randomdev.c
344–346

Doesn’t dofilewrite already do that?

http://fxr.watson.org/fxr/source/kern/sys_generic.c#L568

sys/dev/random/randomdev.c
344–346

Hmm yes, indeed it seems that way. I suspect this isn't the only place this sort of duplication is present in the tree, either.