Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #60893

Bug#897572: [PATCH] Revert "random: fix crng_ready() test"

From "Theodore Y. Ts'o" <tytso@mit.edu>
Newsgroups linux.debian.bugs.dist, linux.debian.kernel
Subject Bug#897572: [PATCH] Revert "random: fix crng_ready() test"
Date 2018-05-07 06:20 +0200
Message-ID <vMFjX-4dk-3@gated-at.bofh.it> (permalink)
References <vMEHf-3YU-3@gated-at.bofh.it> <vLbR0-2oY-1@gated-at.bofh.it> <vMEHf-3YU-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Cross-posted to 2 groups.

Show all headers | View raw


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

Back to linux.debian.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt (missing Kaby Lake firmware?) Ben Caradoc-Davies <ben@transient.nz> - 2018-05-03 04:10 +0200
  Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt Ben Caradoc-Davies <ben@transient.nz> - 2018-05-03 06:50 +0200
  Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt Ben Caradoc-Davies <ben@transient.nz> - 2018-05-03 07:30 +0200
  Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt Ben Caradoc-Davies <ben@transient.nz> - 2018-05-03 07:40 +0200
    Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt Ben Caradoc-Davies <ben@transient.nz> - 2018-05-04 01:40 +0200
    Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt Ben Caradoc-Davies <ben@transient.nz> - 2018-05-04 02:00 +0200
  Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt Ben Hutchings <ben@decadent.org.uk> - 2018-05-05 21:10 +0200
    Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt Ben Caradoc-Davies <ben@transient.nz> - 2018-05-06 02:40 +0200
      Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt Ben Hutchings <ben@decadent.org.uk> - 2018-05-06 05:10 +0200
    Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt Laurent Bigonville <bigon@debian.org> - 2018-05-06 17:30 +0200
      Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt Ben Hutchings <ben@decadent.org.uk> - 2018-05-06 19:50 +0200
  Bug#897572: plymouth: long delay before splashscreen with kernel 4.16 Ben Caradoc-Davies <ben@transient.nz> - 2018-05-06 03:10 +0200
    Bug#897572: plymouth: long delay before splashscreen with kernel 4.16 at46 <at46n@t-online.de> - 2018-05-06 08:50 +0200
      Bug#897572: plymouth: long delay before splashscreen with kernel 4.16 Ben Caradoc-Davies <ben@transient.nz> - 2018-05-07 02:50 +0200
  Bug#897572:  Eric Mill <eric@konklone.com> - 2018-05-06 19:30 +0200
  Bug#897572: [PATCH] Revert "random: fix crng_ready() test" Ben Caradoc-Davies <ben@transient.nz> - 2018-05-07 05:10 +0200
    Bug#897572: [PATCH] Revert "random: fix crng_ready() test" "Theodore Y. Ts'o" <tytso@mit.edu> - 2018-05-07 06:20 +0200
  Bug#897572: [PATCH] Revert "random: fix crng_ready() test" Ben Caradoc-Davies <ben@transient.nz> - 2018-05-07 05:50 +0200
    Bug#897572: [PATCH] Revert "random: fix crng_ready() test" "Theodore Y. Ts'o" <tytso@mit.edu> - 2018-05-07 06:20 +0200
  Bug#897572: urandom hang in early boot Laurent Bigonville <bigon@debian.org> - 2018-05-07 19:40 +0200
    Bug#897572: urandom hang in early boot Ben Caradoc-Davies <ben@transient.nz> - 2018-05-08 01:20 +0200
      Bug#897572: urandom hang in early boot Ben Hutchings <ben@decadent.org.uk> - 2018-05-08 04:10 +0200
        Bug#897572: urandom hang in early boot Ben Caradoc-Davies <ben@transient.nz> - 2018-05-08 06:00 +0200
          Bug#897572: urandom hang in early boot Ben Caradoc-Davies <ben@transient.nz> - 2018-05-08 07:00 +0200
  Bug#897572: urandom hang in early boot Bjørn Mork <bjorn@mork.no> - 2018-05-08 13:40 +0200
    Bug#897572: urandom hang in early boot Yves-Alexis Perez <corsac@debian.org> - 2018-05-09 18:40 +0200
  Bug#897572: getrandom hang in early boot prevents plymouth passphrase entry Esokrates <esokrarkose@gmail.com> - 2018-05-09 11:00 +0200
  Bug#897572: [PATCH] Copy fontconfig .uuid files to avoid getrandom hang in early boot Ben Caradoc-Davies <ben@transient.nz> - 2018-05-10 02:00 +0200

csiph-web