> Fair; it does make sense to re-evaluate the whole thing and find the most generic of solutions, but the issue that triggered this discussion was a sort of regression on systems that do have disks.
Right. On those kinds of systems, persisting some saved state between boots is your best first option. (As other commenters point out, you really don't need very much! 256 bits or 32 bytes is basically adequate.) Any additional entropy you get from device interrupts or machine-dependent random sources like RDRAND are good to mix in.
(I don't think the adversarial RDRAND thread model is a reasonable one, and that has been adequate addressed elsewhere in this thread by tytso, tptacek, and tedunangst. Any adversarial CPU that can defeat cryptographic digest whitening of entropy sources is so sophisticated/privileged it already fully owns your operating system; game over.)
Linux systems already do this, kind of! But Linux has taken the stance that entropy you can't delete from the boot media at the time it is fed into the CSPRNG as entropy doesn't count ("credit") as far as initial seeding, and that decision is what moots its utility for early CSPRNG availability. It's not an unreasonably paranoid take, but not an especially practical one (IMO). I suspect the net effect on security, holistically, is negative.
> (Your point also raises the question: on systems that don't have disks, how are requests for early-boot entropy handled?)
Depends which subsystem you ask and how you ask it, right? And whether or not a jitter entropy scheme is enabled in the kernel. (I might be misunderstanding your question, sorry if that's the case.) If you ask /dev/random or getrandom(~GRND_NONBLOCK), they'll block until the CSPRNG is satisfied enough entropy is available. If you ask /dev/urandom, it just spews unseeded and likely predictable garbage at you. If you ask getrandom(GRND_NONBLOCK), it returns -1/EAGAIN.
> (I might be misunderstanding your question, sorry if that's the case.)
Not entirely, but I think my question was just more narrow. Considering the case that started this off (machines that used to work, now hanging on boot because of lack of entropy, triggered by too few disk interrupts), I don't get how this generalizes. If you take that same system, and remove the disk (replacing it with netboot or whatever), how would it ever boot, at least not without making some changes to how early entropy is seeded? I guess in the netboot case you end up with the timing of network interrupts that you can feed into the entropy pool, but this whole thing just feels off to me.
If a system was relying on a specific, inefficient set of disk access to give it just enough entropy to get through early boot, and that making the FS code more efficient caused it to fail to have enough entropy, I'd suggest that (likely unbeknownst to the system administrators), this system was already pretty broken. I get why Torvalds decided to bucket this under the "we don't break userspace" umbrella, and appreciate the care he takes to that sort of thing, but suggesting that "FS access patterns during early boot" is sorta a part of the kernel's ABI is... a bit too incredible for me to take seriously.
Right. On those kinds of systems, persisting some saved state between boots is your best first option. (As other commenters point out, you really don't need very much! 256 bits or 32 bytes is basically adequate.) Any additional entropy you get from device interrupts or machine-dependent random sources like RDRAND are good to mix in.
(I don't think the adversarial RDRAND thread model is a reasonable one, and that has been adequate addressed elsewhere in this thread by tytso, tptacek, and tedunangst. Any adversarial CPU that can defeat cryptographic digest whitening of entropy sources is so sophisticated/privileged it already fully owns your operating system; game over.)
Linux systems already do this, kind of! But Linux has taken the stance that entropy you can't delete from the boot media at the time it is fed into the CSPRNG as entropy doesn't count ("credit") as far as initial seeding, and that decision is what moots its utility for early CSPRNG availability. It's not an unreasonably paranoid take, but not an especially practical one (IMO). I suspect the net effect on security, holistically, is negative.
> (Your point also raises the question: on systems that don't have disks, how are requests for early-boot entropy handled?)
Depends which subsystem you ask and how you ask it, right? And whether or not a jitter entropy scheme is enabled in the kernel. (I might be misunderstanding your question, sorry if that's the case.) If you ask /dev/random or getrandom(~GRND_NONBLOCK), they'll block until the CSPRNG is satisfied enough entropy is available. If you ask /dev/urandom, it just spews unseeded and likely predictable garbage at you. If you ask getrandom(GRND_NONBLOCK), it returns -1/EAGAIN.