Page MenuHomeFreeBSD

kern: harvest entropy from callouts
ClosedPublic

Authored by kevans on Feb 3 2022, 12:18 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Jan 13, 4:09 AM
Unknown Object (File)
Dec 24 2022, 7:46 PM
Unknown Object (File)
Dec 24 2022, 10:59 AM
Unknown Object (File)
Dec 24 2022, 10:58 AM
Unknown Object (File)
Dec 24 2022, 10:58 AM
Unknown Object (File)
Dec 24 2022, 10:39 AM
Unknown Object (File)
Dec 17 2022, 10:34 AM
Unknown Object (File)
Dec 14 2022, 3:04 AM
Subscribers

Details

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

Diff Detail

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

Event Timeline

no, that was correct the first time -- sorry

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 marked 2 inline comments as done.

Reorder RANDOM_CALLOUT to avoid renumbering RANDOM_FS_ATIME and RANDOM_UMA

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.

This revision is now accepted and ready to land.Feb 3 2022, 4:18 AM
markm added a subscriber: markm.

Accepting in retrospect. Thanks!

This revision was automatically updated to reflect the committed changes.