Hi! On Mon, 2018-05-07 at 01:04:26 +0100, Ben Hutchings wrote: > Source: libbsd > Version: 0.8.7-1 > Severity: serious > Tags: upstream
> The manual page for arc4random_buf() says "High quality 32-bit > pseudo-random numbers are generated very quickly." This promise is > false, and it can never be true in general! > > On recent Linux kernel versions arc4random_buf() uses the getrandom() > system call where available. getrandom() is documented to block > (or return an error, depending on the flags parameter) when > the kernel's RNG does not have enough entropy available. It was > recently found that the RNG was unblocking getrandom() too early > (CVE-2018-1108). > > But the fix for this means that getrandom() and arc4random_buf() may > block until a minute or even longer after boot. Since > gnome-session-binary calls arc4random_buf() via > IceGenerateMagicCookie(), fixing the kernel causes a "blank screen" > regression for some systems. > > I don't know quite how we're going to solve this, but at the very > least the manual page for arc4random_buf() must clarify whether it > is intended to provide high quality, or non-blocking, behaviour. I'll just pull in the latest update from OpenBSD, which seems to have addresses this problem in Linux: <https://github.com/openbsd/src/blob/master/lib/libcrypto/arc4random/getentropy_linux.c> And I've to agree with the comment there, that the behavior in Linux is less than ideal. (While at it, I'll be checking any other imported files for updates.) Thanks, Guillem
