kern: harvest entropy from callouts

[kevans]

Summary

74cf7cae4d22 ("softclock: Use dedicated ithreads for running callouts.")
switched callouts away from the swi infrastructure. It turns out that
this was a major source of entropy in early boot, which we've now lost.

As a result, first boot on hardware without a 'fast' entropy source
would block waiting for fortuna to be seeded with little hope of
progressing without manual intervention.

Let's resolve it by explicitly harvesting entropy in callout_process()
if we've handled any callouts. cc/curthread/now seem to be reasonable
sources of entropy, so use those.

Discussed with: jhb
Reported by: many

[kevans]

curthread -> cc_thread

[kevans]

no, that was correct the first time -- sorry

[cem]

Looks fine to me. We should probably also actively feed jitter entropy if we hit the blocked state on boot, but that doesn't mean we shouldn't just do this first.

sys/kern/kern_timeout.c

434–437

The native entropy input size is like, 8 bytes or something, but I believe we squash random_harvest_queue inputs with a fast hash or something so this should be ok. Double check?

sys/sys/random.h

87

I think we might want to add this at the end of the ENVIRONMENTAL section to avoid renumbering FS_ATIME and UMA. But I'm not confident about that.

[kevans]

Reorder RANDOM_CALLOUT to avoid renumbering RANDOM_FS_ATIME and RANDOM_UMA

[kevans]

sys/kern/kern_timeout.c

434–437

Right, larger inputs get squashed with jenkins_hash: http://bxr.su/FreeBSD/sys/dev/random/random_harvestq.c#535

sys/sys/random.h

87

I couldn't find a reason specifically to avoid renumbering, but I also have no objection to moving it -- it looks like we can avoid a module rebuild with it at the end of the environmental section, we don't allow modification of pure sources via harvestmask anyways and a mismatch of, e.g., RANDOM_PURE_VIRTIO, in hc_destination seems relatively harmless.

[markm]

Accepting in retrospect. Thanks!