# Background
The Linux kernel random number generator (RNG) historically supported
two character devices for reading random data:
* `/dev/urandom`: non-blocking, may be predictable if called soon after
boot or based on other output
* `/dev/random`: blocking, intended to be cryptographically secure
Since Linux 3.19 it has also supported a `getrandom()` system call,
which provides flags for cryptographically secure behaviour
(`GRND_RANDOM`) and non-blocking behaviour (`GRND_NONBLOCK`).
Crucially, this call should never return predictable data after boot -
it will either block or return an error, depending on whether
`GRND_NONBLOCK` is used.
# Security flaw and initial fix
Recently it was discovered that getrandom() could return successfully
before the RNG was really ready to produce unpredictable data. This
issue was designated as CVE-2018-1108, and was fixed in Linux 4.17-rc2
and various stable updates.
We fixed CVE-2018-1108 with an update to stretch last week
(DSA-4188-1). The kernel versions in wheezy and jessie do not provide
getrandom().
# Regression
The version of glibc in stretch does not provide access to getrandom(),
but some packages in stable use syscall() to call it anyway, including:
* krb5: k5_get_os_entropy()
* libbsd: arc4_random_buf(). This is used by many other packages
including libICE, and so indirectly by gnome-session.
Following DSA-4188-1, it turned out that the RNG did not become ready
on some systems until several minutes after boot, causing severe
regressions for GNOME/gdm (#897631, #897632) and Kerberos (#897599,
#897917). We therefore reverted the fix in yesterday's update
(DSA-4196-1).
# Options for a new fix
It is unlikely that any further fix will be forthcoming on the kernel
side, so I believe that we need to do one of:
1. Add entropy to the kernel during boot; either:
a. Improve systemd-random-seed
b. Recommend use of haveged
2. For each affected userland package, either:
a. Revert to using /dev/urandom
b. Tolerate a longer wait for getrandom() to return
I asked about haveged on Twitter, and got into a discussion with Jann
Horn (who reported the original issue). He pointed out that the
systemd-random-seed service already saves and restores some random data
between boots. It currently doesn't tell the RNG that this should be
treated as adding to available entropy, so it doesn't help to unblock
getrandom(). It also doesn't fully protect against using the same
saved data twice, which would be a prerequisite.
The libbsd maintainer (Guillem Jover) favours option 2a.
One of the krb5 maintainers (Benjamin Kaduk) favours option 2b, and
also proposed that systemd could provide a wait-for-rng-ready unit to
support this.
*If* these are the only users in stable, then it may be that it would
be sufficient to do stable updates for them and then for linux. But
I'm not sure that they are, so we may need to pursue option 1 as well.
I would like to hear opinions from the release team and the systemd
maintainers on these options.
Ben.
--
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
- Bill Gates
Attachment:
signature.asc
Description: This is a digitally signed message part