On Sun, 2018-05-06 at 12:33 +1200, Ben Caradoc-Davies wrote: > On 06/05/18 07:01, Ben Hutchings wrote: > > I wonder if this is related to the recent RNG changes. It seems that > > many programs have started using blocking RNG functions like > > getentropy(), and now that the kernel is more conservative in its > > initial entropy estimation they can block for a long time. Keyboard or > > mouse input adds entropy. > > At a guess, plymouth is starting the X server and the X server wants > > random bits for MIT-MAGIC-COOKIE authentication. > > Ben, I think you might be right. Only a few mouse wiggles are sufficient > to trigger the appearance of the plymouth LUKS screen. I guess that > mouse activity is a richer source of entropy than key presses. > > So, where to from here? Should this be reassigned to plymouth or xorg?
Now that I've looked, it appears that Xorg is actually still using /dev/urandom (via arc4random_buf() in libbsd). So far as I know, reads from /dev/urandom have historically succeeded without blocking, even when there is very little entropy available. Since many daemons depend on this I think it has to be maintained. But so far as I can see from the kernel code, that hasn't changed - only the newer getentropy() function is more likely to block. So I'm quite confused. Ben. -- Ben Hutchings If more than one person is responsible for a bug, no one is at fault.
signature.asc
Description: This is a digitally signed message part
