randomdev: Remove 100 ms sleep from write routine

[cperciva]

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.

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

[cperciva]

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.

[cem]

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!

[cperciva]

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.

[cem]

sys/dev/random/randomdev.c

344–346

Doesn’t dofilewrite already do that?

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

[cperciva]

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.