Bug#898088: arc4random_buf() may block for a long time
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.
Ben.
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Reply to: