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

Groups > linux.debian.kernel > #60803 > unrolled thread

Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt (missing Kaby Lake firmware?)

Started byBen Caradoc-Davies <ben@transient.nz>
First post2018-05-03 04:10 +0200
Last post2018-05-10 02:00 +0200
Articles 8 on this page of 28 — 9 participants

Back to article view | Back to linux.debian.kernel

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#60916 — Bug#897572: urandom hang in early boot

FromBen Caradoc-Davies <ben@transient.nz>
Date2018-05-08 01:20 +0200
SubjectBug#897572: urandom hang in early boot
Message-ID<vMXAe-7Xs-5@gated-at.bofh.it>
In reply to#60908
On 08/05/18 05:34, Laurent Bigonville wrote:
> Apparently it's also happening for other applications that are starting 
> later during the boot like GDM.
> Somebody has reported an issue on IRC where GDM was taking upto 8 
> minutes to start (dmesg was showing several "random: systemd: 
> uninitialized urandom read (16 bytes read)" during boot)
> That problem might impact lot of people I'm afraid.

systemd is the underlying cause: plymouthd uses libudev1, which expects 
getrandom/urandom(?) to never block:
https://github.com/systemd/systemd/blob/master/src/basic/random-util.c#L34

See discussion here about systemd usage of random numbers:
systemd reads from urandom before initialization
https://github.com/systemd/systemd/issues/4167

The new problem is that 43838a23a05f ("random: fix crng_ready() test") 
turns an ugly warning and cryptographic weakness into an indefinite 
hang. Security achieved!

Kind regards,

-- 
Ben Caradoc-Davies <ben@transient.nz>
Director
Transient Software Limited <https://transient.nz/>
New Zealand

[toc] | [prev] | [next] | [standalone]

#60917 — Bug#897572: urandom hang in early boot

FromBen Hutchings <ben@decadent.org.uk>
Date2018-05-08 04:10 +0200
SubjectBug#897572: urandom hang in early boot
Message-ID<vN0eJ-19n-1@gated-at.bofh.it>
In reply to#60916

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2018-05-08 at 11:12 +1200, Ben Caradoc-Davies wrote:
> On 08/05/18 05:34, Laurent Bigonville wrote:
> > Apparently it's also happening for other applications that are starting 
> > later during the boot like GDM.
> > Somebody has reported an issue on IRC where GDM was taking upto 8 
> > minutes to start (dmesg was showing several "random: systemd: 
> > uninitialized urandom read (16 bytes read)" during boot)
> > That problem might impact lot of people I'm afraid.
> 
> systemd is the underlying cause: plymouthd uses libudev1, which expects 
> getrandom/urandom(?) to never block:
> https://github.com/systemd/systemd/blob/master/src/basic/random-util.c#L34
> 
> See discussion here about systemd usage of random numbers:
> systemd reads from urandom before initialization
> https://github.com/systemd/systemd/issues/4167
> 
> The new problem is that 43838a23a05f ("random: fix crng_ready() test") 
> turns an ugly warning and cryptographic weakness into an indefinite 
> hang. Security achieved!

You keep saying this, but based on my reading of the code I don't see
how reads from /dev/urandom can end up blocking.

(For the time being I've concentrated on fixing stretch, so I haven't
done substantial testing in unstable.)

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained
by stupidity.

[toc] | [prev] | [next] | [standalone]

#60922 — Bug#897572: urandom hang in early boot

FromBen Caradoc-Davies <ben@transient.nz>
Date2018-05-08 06:00 +0200
SubjectBug#897572: urandom hang in early boot
Message-ID<vN1Xc-25k-7@gated-at.bofh.it>
In reply to#60917
On 08/05/18 14:00, Ben Hutchings wrote:
> You keep saying this, but based on my reading of the code I don't see
> how reads from /dev/urandom can end up blocking.

Ben, I think you are right. I have picked through the code in detail and 
none of the changes affect any substantive logic (except logging). I do 
not think urandom_read can ever block. The urandom warning may be from a 
previous read before the hang: related, but a red herring.

The *one* substantive change that is affected is getrandom:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n2007

If something calls getrandom without GRND_NONBLOCK while crng_init==1 
(during early boot):

- Before 43838a23a05f ("random: fix crng_ready() test"), this just falls 
thorough to urandom_read and everything seems to work (but is not 
cryptographically secure).

- After 43838a23a05f ("random: fix crng_ready() test"), this will call 
wait_for_random_bytes and hang waiting on mouse wiggles 
(cryptographically secure).

But what is calling getrandom without GRND_NONBLOCK? I could find 
nothing in the plymouth or systemd/udev codebase. Or is it something 
they spawn? I even read the plymouth softwaves.script.

Kind regards,

-- 
Ben Caradoc-Davies <ben@transient.nz>
Director
Transient Software Limited <https://transient.nz/>
New Zealand

[toc] | [prev] | [next] | [standalone]

#60923 — Bug#897572: urandom hang in early boot

FromBen Caradoc-Davies <ben@transient.nz>
Date2018-05-08 07:00 +0200
SubjectBug#897572: urandom hang in early boot
Message-ID<vN2Tf-2GZ-1@gated-at.bofh.it>
In reply to#60922
On 08/05/18 15:55, Ben Caradoc-Davies wrote:
> If something calls getrandom without GRND_NONBLOCK while crng_init==1 
> (during early boot)
I now have conclusive evidence that this is the cause of the hang. If I 
add a printk:

diff --git a/drivers/char/random.c b/drivers/char/random.c
index cd888d4ee605..b7358cc32f42 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -2021,6 +2021,9 @@ SYSCALL_DEFINE3(getrandom, char __user *, buf, 
size_t, count,
         if (!crng_ready()) {
                 if (flags & GRND_NONBLOCK)
                         return -EAGAIN;
+               printk(KERN_NOTICE "random: %s: getrandom without "
+                               "GRND_NONBLOCK while crng not ready\n",
+                               current->comm);
                 ret = wait_for_random_bytes();
                 if (unlikely(ret))
                         return ret;

I get these at the console just before the hang:

random: plymouthd: uninitialized urandom read (8 bytes read)
random: plymouthd: uninitialized urandom read (8 bytes read)
random: plymouthd: getrandom without GRND_NONBLOCK while crng not ready

Kind regards,

-- 
Ben Caradoc-Davies <ben@transient.nz>
Director
Transient Software Limited <https://transient.nz/>
New Zealand

[toc] | [prev] | [next] | [standalone]

#60929 — Bug#897572: urandom hang in early boot

FromBjørn Mork <bjorn@mork.no>
Date2018-05-08 13:40 +0200
SubjectBug#897572: urandom hang in early boot
Message-ID<vN98l-6zi-5@gated-at.bofh.it>
In reply to#60803
Ben Hutchings <ben@decadent.org.uk> writes:
> On Tue, 2018-05-08 at 11:12 +1200, Ben Caradoc-Davies wrote:
>> On 08/05/18 05:34, Laurent Bigonville wrote:
>> > Apparently it's also happening for other applications that are starting 
>> > later during the boot like GDM.
>> > Somebody has reported an issue on IRC where GDM was taking upto 8 
>> > minutes to start (dmesg was showing several "random: systemd: 
>> > uninitialized urandom read (16 bytes read)" during boot)
>> > That problem might impact lot of people I'm afraid.
>> 
>> systemd is the underlying cause: plymouthd uses libudev1, which expects 
>> getrandom/urandom(?) to never block:
>> https://github.com/systemd/systemd/blob/master/src/basic/random-util.c#L34
>> 
>> See discussion here about systemd usage of random numbers:
>> systemd reads from urandom before initialization
>> https://github.com/systemd/systemd/issues/4167
>> 
>> The new problem is that 43838a23a05f ("random: fix crng_ready() test") 
>> turns an ugly warning and cryptographic weakness into an indefinite 
>> hang. Security achieved!
>
> You keep saying this, but based on my reading of the code I don't see
> how reads from /dev/urandom can end up blocking.

It's a bit convoluted, but if I read the code correctly then
acquire_random_bytes() falls back to busy-loop reading from /dev/urandom
until it has the requested number of bytes if 'high_quality_required' is
true.

There aren't more than two such calls, but one of then is
sd_id128_randomize() which calls acquire_random_bytes(&t, sizeof t, true).

And sd_id128_randomize() is called from all over the place.  I haven't
bothered looking at all the call sites, but would be surprised if not at
least one of them is unconditionally called at boot.

If I am correct, then I guess this is a systemd bug?


Bjørn

[toc] | [prev] | [next] | [standalone]

#60942 — Bug#897572: urandom hang in early boot

FromYves-Alexis Perez <corsac@debian.org>
Date2018-05-09 18:40 +0200
SubjectBug#897572: urandom hang in early boot
Message-ID<vNAid-5T2-9@gated-at.bofh.it>
In reply to#60929

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2018-05-08 at 13:23 +0200, Bjørn Mork wrote:
> And sd_id128_randomize() is called from all over the place.  I haven't
> bothered looking at all the call sites, but would be surprised if not at
> least one of them is unconditionally called at boot.
> 
> If I am correct, then I guess this is a systemd bug?

It might be (I took the liberty to add your findings to https://github.com/sys
temd/systemd/issues/4167).

In our case, as far as I can tell since we're still in the initramfs, systemd
is not yet PID1, but we do use udev which might have the same issue.

Regards,
-- 
Yves-Alexis

[toc] | [prev] | [next] | [standalone]

#60938 — Bug#897572: getrandom hang in early boot prevents plymouth passphrase entry

FromEsokrates <esokrarkose@gmail.com>
Date2018-05-09 11:00 +0200
SubjectBug#897572: getrandom hang in early boot prevents plymouth passphrase entry
Message-ID<vNt73-1yH-1@gated-at.bofh.it>
In reply to#60803
I confirm this issue.
It affects plymouth in general, not related to any passphrase entry.
Booting in recovery mode helps to get around the plymouth problem, but 
if there is not enough entropy gdm3 will simply not start. Pressing 
keys/switching VTs leads to the crng_init finished message to be printed 
and gdm3 starts after that.

Please consider adjusting the importance of the issue, it makes the 
system almost unbootable for regular users.

[toc] | [prev] | [next] | [standalone]

#60957 — Bug#897572: [PATCH] Copy fontconfig .uuid files to avoid getrandom hang in early boot

FromBen Caradoc-Davies <ben@transient.nz>
Date2018-05-10 02:00 +0200
SubjectBug#897572: [PATCH] Copy fontconfig .uuid files to avoid getrandom hang in early boot
Message-ID<vNHa1-1vD-1@gated-at.bofh.it>
In reply to#60803
Fixes:
Bug#897572: getrandom hang in early boot prevents plymouth passphrase entry
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572

Signed-off-by: Ben Caradoc-Davies <ben@transient.nz>
---
 debian/local/plymouth.hook | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/debian/local/plymouth.hook b/debian/local/plymouth.hook
index fe44511..bde2d2c 100644
--- a/debian/local/plymouth.hook
+++ b/debian/local/plymouth.hook
@@ -99,12 +99,16 @@ case "${THEME_NAME}" in
 			mkdir -p "${DESTDIR}/usr/share/fonts/truetype/dejavu"
 			cp -a /usr/share/fonts/truetype/dejavu/DejaVuSerif.ttf "${DESTDIR}/usr/share/fonts/truetype/dejavu"
 			cp -a /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf  "${DESTDIR}/usr/share/fonts/truetype/dejavu"
+			cp -a /usr/share/fonts/truetype/dejavu/.uuid "${DESTDIR}/usr/share/fonts/truetype/dejavu"
 		else
 			# wheezy
 			mkdir -p "${DESTDIR}/usr/share/fonts/truetype/ttf-dejavu"
 			cp -a /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf "${DESTDIR}/usr/share/fonts/truetype/ttf-dejavu"
 			cp -a /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf  "${DESTDIR}/usr/share/fonts/truetype/ttf-dejavu"
+			cp -a /usr/share/fonts/truetype/ttf-dejavu/.uuid "${DESTDIR}/usr/share/fonts/truetype/ttf-dejavu"
 		fi
+		cp -a /usr/share/fonts/truetype/.uuid "${DESTDIR}/usr/share/fonts/truetype"
+		cp -a /usr/share/fonts/.uuid "${DESTDIR}/usr/share/fonts"
 
 		# pango
 		if ls /usr/lib/@DEB_HOST_MULTIARCH@/pango/1* > /dev/null 2>&1
-- 
Ben Caradoc-Davies <ben@transient.nz>
Director
Transient Software Limited <https://transient.nz/>
New Zealand

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.kernel

csiph-web