Linux 5.4 Will Try When Needed To Actively Generate RNG Entropy To Avoid Boot Problems

[phoronix]

Phoronix: Linux 5.4 Will Try When Needed To Actively Generate RNG Entropy To Avoid Boot Problems

Linux 5.4-rc1 didn't end up being released on Sunday night as is tradition but instead there were some last-minute critical patches that landed around the kernel's handling of the random number generator / entropy at boot-time...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-5.4-Actively-Gen-Entropy

[tildearrow]

GNOME/GDM requesting secure randomness at boot time,

But why? Is that really necessary?

[nanonyme]

But why? Is that really necessary?

Well, if you look more carefully, you notice the real culprit was Ext4. So this is mostly a "don't break userspace" thing rather than just responding to pleads from userspace developers to add this.

[skeevy420]

But why?

Secure key rings, encrypted virtual filesystems, and whatnot.

Is that really necessary?

Yes or someone wouldn't be using it.

[starshipeleven]

But why? Is that really necessary?

Seems like a bug.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f2dc2798b81531fd93a3b9b7c39da47ec689e55

This is admittedly partly "for discussion". We need to have a way forward for the boot time deadlocks where user space ends up waiting for more entropy, but no entropy is forthcoming because the system is entirely idle just waiting for something to happen.

While this was triggered by what is arguably a user space bug with GDM/gnome-session asking for secure randomness during early boot, when they didn't even need any such truly secure thing, the issue ends up being that our "getrandom()" interface is prone to that kind of confusion, because people don't think very hard about whether they want to block for sufficient amounts of entropy.

The approach here-in is to decide to not just passively wait for entropy to happen, but to start actively collecting it if it is missing. This is not necessarily always possible, but if the architecture has a CPU cycle counter, there is a fair amount of noise in the exact timings of reasonably complex loads.

We may end up tweaking the load and the entropy estimates, but this should be at least a reasonable starting point.

As part of this, we also revert the revert of the ext4 IO pattern improvement that ended up triggering the reported lack of external entropy.

[starshipeleven]

Secure key rings, encrypted virtual filesystems, and whatnot.



Yes or someone wouldn't be using it.

Torvalds disagrees (see above)

[skeevy420]

Torvalds disagrees (see above)

I saw that, but, IMHO, I can't really blame Gnome for wanting to try to be as secure as possible and erring on the side of caution in this day and age.

Besides, while whatever Gnome is using it for apparently doesn't need it, it's great that more eyes on a topic found a bug that could have hindered a systemd service, LUKS, etc that actually does need it and is what makes open source great.

[starshipeleven]

I saw that, but, IMHO, I can't really blame Gnome

I don't know and I'm not automatically assuming they really need it. There are plenty of applications that need randomness for non-security purposes and would be totally fine with low quality entropy.

more eyes on a topic found a bug that could have hindered a systemd service

That's like a year or so too late for that. System hangs on boot (with systemd and other things that actually need the entropy) because of lack of entropy were first reported ages ago.
Sane distros are already shipping daemons like haveged or rngd that fill the pool with lower-quality entropy.

[tildearrow]

Secure key rings, encrypted virtual filesystems, and whatnot.



Yes or someone wouldn't be using it.

Do we need randomness to read an encrypted filesystem? I've heard it may be needed for writes, but what about reads?

[skeevy420]

Do we need randomness to read an encrypted filesystem? I've heard it may be needed for writes, but what about reads?

Don't know, I'm not really all that sure on the ins and outs of encryption to know one way or the other outside of generic crap like "fast and randomized entropy = good" & "1024 > 512"...