random: Ingest extra fast entropy when !seeded
ClosedPublic
Actions

Authored by cperciva on Jul 13 2022, 12:48 AM.

Details

Reviewers

delphij

Group Reviewers

csprng

Commits

rG0811ce572394: random: Ingest extra fast entropy when !seeded

Summary

We periodically ingest entropy from pollable entropy sources, but only
8 bytes at a time and only occasionally enough to feed all of Fortuna's
pools once per second. This can result in Fortuna remaining unseeded
for a nontrivial amount of time when there is no entropy passed in from
the boot loader, even if RDRAND is available to quickly provide a large
amount of entropy.

Detect in random_sources_feed if we are not yet seeded, and increase the
amount of immediate entropy harvesting we perform, in order to "fill"
Fortuna's entropy pools and avoid having

random: randomdev_wait_until_seeded unblock wait

stall the boot process when entropy is available.

This speeds up the FreeBSD boot in the Firecracker VM by 2.3 seconds.

Discussed with: cem
Sponsored by: https://www.patreon.com/cperciva

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 46402
Build 43291: arc lint + arc unit

Event Timeline

cperciva created this revision.Jul 13 2022, 12:48 AM

Herald added subscribers: jmg, imp. · View Herald TranscriptJul 13 2022, 12:48 AM

cperciva requested review of this revision.Jul 13 2022, 12:48 AM

Harbormaster completed remote builds in B46402: Diff 108088.Jul 13 2022, 12:48 AM

cperciva added a reviewer: csprng.Jul 13 2022, 12:51 AM

Discussed with: cem

Is maybe overselling it. Like I said in email, I don't think this is the right place to do it. Functionally, I don't think it will break anything.

I'd be happy to green-light this, but I also wonder if there is not a better way. For now, I'm at "no objection" for a merge, but with a request for further exploration of e.g. cached boot-time entropy stashing. (Could a VM do that?)

This looks good to me in principle.

Before committing, could you please add comments explaining why we are doing this, and ideally, perhaps also how these values were chosen (see my comment inline)?

sys/dev/random/random_harvestq.c
257	I'd like to check if my understanding was correct for the `!ra_seeded()` case: The `64` was chosen because it's the `RANDOM_FORTUNA_DEFPOOLSIZE` The intention was to attempt to fully populate all pools with fast source data in one `random_kthread` interation We then iterate over all live sources: Realistically, most system has only one live source, that's the CPU provided RNG. For systems where no live source is available, the code below wold be no-op (we then fall back to waiting for other sources, which we have to do anyways) For systems where multiple live sources are available (virtio-rng, or crypto hardware), we could potentially harvest more than we need (but I think this is Okay because we only do the full harvest once as long as they are not all too slow). So the net effect for a typical `!ra_seeded()` case is that when the `random_kthread()` calls `random_sources_feed()`, we attempt to fully fill Fortuna's entropy pools (@10Hz, but hopefully only once) with live sources. For systems with boot entropy loaded, because we already primed RNG well before the random_kthread, this would be a no-op.
258	If the understanding above was correct, should this be changed to `sizeof(entropy)` instead?

This revision is now accepted and ready to land.Jul 13 2022, 8:12 AM

In D35802#812428, @markm wrote:

I'd be happy to green-light this, but I also wonder if there is not a better way. For now, I'm at "no objection" for a merge, but with a request for further exploration of e.g. cached boot-time entropy stashing. (Could a VM do that?)

I think there is no standard way of doing it (for supplying (potentially continuous stream of) entropy to the guest, VirtIO RNG is a relatively standardized way that works for many hypervisors). I think other operating systems might just happily take VirtIO RNG, or RDSEED along with their regular entropy sources to perform the initialization.

Doing the harvesting in random_sources_feed() seems to be reasonable: it would only do the actual work after the live entropy source is registered, and that's well after random_harvestq_prime so if there is saved boot entropy that was loaded by loader, we wouldn't be performing the "fast" fill at all.

Something to keep in mind re: exactly 64 is that it's possible for entropy sources to return less entropy than was requested, if for example some internal state means they don't have anything available at the moment. That's one reason I prefer polling repeatedly until seeded (or some spin threshold is crossed).

In D35802#812428, @markm wrote:

I'd be happy to green-light this, but I also wonder if there is not a better way. For now, I'm at "no objection" for a merge, but with a request for further exploration of e.g. cached boot-time entropy stashing. (Could a VM do that?)

In most cases we have entropy provided to us by the boot loader, either from UEFI (if the platform implements UEFI RNG functionality) or from /boot/entropy (if it's not the first time the system boots). The case where I'm tripping over this is the first (and typically *only*) time the VM in question boots, and it's booting without the boot loader so we can't get the entropy that way (even if /boot/entropy existed).

emaste added a subscriber: emaste.Jul 17 2022, 6:09 PM

Update to add comments and fix sizeof(entropy).

This revision now requires review to proceed.Jul 20 2022, 5:05 AM

Harbormaster completed remote builds in B46493: Diff 108356.Jul 20 2022, 5:05 AM

@delphij Thanks for the catch re HARVESTSIZE vs sizeof(entropy)... I keep on forgetting that HARVESTSIZE is weirdly measured in words rather than bytes.

I added a lengthy comment which I think helps explain what's going on. Please let me know if anything is still unclear.

delphij accepted this revision.Jul 20 2022, 6:02 AM

This revision is now accepted and ready to land.Jul 20 2022, 6:02 AM

Closed by commit rG0811ce572394: random: Ingest extra fast entropy when !seeded (authored by cperciva). · Explain WhyJul 20 2022, 7:00 AM

This revision was automatically updated to reflect the committed changes.

cperciva added a commit: rG0811ce572394: random: Ingest extra fast entropy when !seeded.