On Mon, May 07, 2018 at 02:58:03PM +1200, Ben Caradoc-Davies wrote:
> This reverts commit 43838a23a05f ("random: fix crng_ready() test"),
> which causes urandom to hang in early boot even when crng_init==1.
>
> One impact of this hang is that it prevents display of the plymouth
> graphical passphrase prompt required to proceed with boot. In the
> absence of sources of entropy (such as a wired network adapter?), the
> hang is indefinite. User workarounds are to generate entropy with key
> presses or mouse motion, or to disable the plymouth graphical
> passphrase prompt by removing "splash" from the kernel command line.
Unfortunately, commit 43838a23a05f is needed to address CVE-2018-1108,
which was reported by Jann Horn of Google's Project Zero. There are
real problems with allowing programs to assume that they have a fully
initialized cryptographic random number generation when they don't.
For an example of the sort of rather embarssing security oopsie that
can result, please see [1]
[1] https://factorable.net/paper.html
For this reason, I don't really recommend reverting the commit. Jann
and I did see if we it was blatently exploitable, and I don't think
it's quite as bad, as say, Debian's OpenSSL RNG bug[2]. However, if
you revert the change, I am not sure whether or not a cyber attacker
with the resources of nation-state could be able to find a way predict
random numbers generated during early system startup, for at least
some classes of hardware.
[2] https://www.debian.org/security/2008/dsa-1571
There are discussions about this on LKML; the best way to fix the
problem is to address the userspace problem. Does userspace *really*
need cryptographic randomness before the user logs in? And if so,
*why*? Generating long-term public keys right after a machine is
first booted is a really bad idea.
Regards,
- Ted
