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?)

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 1 of 2  [1] 2  Next page →

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

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

Package: linux
Version: linux-image-4.16.0-1-amd64
Severity: normal

Dear Maintainer,

booting with linux-image-4.16.0-1-amd64 causes the plymouth LUKS prompt to not
be displayed, preventing password entry and thus boot. System can still be
rebooted with Ctrl-Alt-Del.

The system is an Intel Kaby Lake i7 7700 running on its HD Graphics 630 iGPU.
Missing firmware errors are seen in the logs and at the unusable boot screen
(photo attached):

May  3 13:40:17 ripley kernel: [    0.991156] i915 0000:00:02.0: firmware:
failed to load i915/kbl_dmc_ver1_04.bin (-2)
May  3 13:40:17 ripley kernel: [    0.991158] firmware_class: See
https://wiki.debian.org/Firmware for information about missing firmware
May  3 13:40:17 ripley kernel: [    0.991160] i915 0000:00:02.0: Direct
firmware load for i915/kbl_dmc_ver1_04.bin failed with error -2
May  3 13:40:17 ripley kernel: [    0.991163] i915 0000:00:02.0: Failed to load
DMC firmware i915/kbl_dmc_ver1_04.bin. Disabling runtime power management.
May  3 13:40:17 ripley kernel: [    0.991165] i915 0000:00:02.0: DMC firmware
homepage: https://01.org/linuxgraphics/downloads/firmware

This missing firmware is also noted when running update-initramfs:

# update-initramfs -u -k 4.16.0-1-amd64
update-initramfs: Generating /boot/initrd.img-4.16.0-1-amd64
W: Possible missing firmware /lib/firmware/i915/skl_dmc_ver1_27.bin for module
i915
W: Possible missing firmware /lib/firmware/i915/kbl_dmc_ver1_04.bin for module
i915
W: Possible missing firmware /lib/firmware/i915/kbl_guc_ver9_39.bin for module
i915
W: Possible missing firmware /lib/firmware/i915/bxt_guc_ver9_29.bin for module
i915
W: Possible missing firmware /lib/firmware/i915/skl_guc_ver9_33.bin for module
i915

Workaround is to remove "splash" from the kernel command line.

Kind regards,
Ben.



-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.16.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

[toc] | [next] | [standalone]

#60805 — Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

Manually installing kbl_dmc_ver1_04.bin and kbl_guc_ver9_39.bin from 
<https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915> 
into /lib/firmware/i915 and running update-initramfs does not fix, so it 
it not a firmware issue. The firmware errors are removed, leaving a 
black screen with a solitary blinking cursor.

For the record, manual firmware installation is performed with:

cp kbl_dmc_ver1_04.bin kbl_guc_ver9_39.bin /lib/firmware/i915
chmod 644 /lib/firmware/i915
update-initramfs -u -k 4.16.0-1-amd64

(The HUC firmware is unchanged from the dpkg on unstable.)

Kind regards,

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

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

#60806 — Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

Trying to switch consoles with Alt-F1 to Alt-F7 many time eventually 
causes the plymouth LUKS screen to appear. This does not seem to be 
deterministic.

Kind regards,

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

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

#60808 — Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

And I should mention that my plymouth LUKS screen was working fine with 
kernels up to and including linux-image-4.15.0-3-amd64 4.15.17-1.

Kind regards,

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

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

#60826 — Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

On 03/05/18 17:37, Ben Caradoc-Davies wrote:
> And I should mention that my plymouth LUKS screen was working fine with 
> kernels up to and including linux-image-4.15.0-3-amd64 4.15.17-1.

And to eliminate any other change on the system as a cause, I rebuilt 
initrd.img for both packages and the plymouth LUKS screen failure was 
seen *only* for linux-image-4.16.0-1-amd64:

update-initramfs -u -k 4.15.0-3-amd64
update-initramfs -u -k 4.16.0-1-amd64

Installed kernel packages are:

linux-image-4.15.0-3-amd64 4.15.17-1
linux-image-4.16.0-1-amd64 4.16.5-1

Kind regards,

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

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

#60827 — Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

More findings:

- Adding i915 to /etc/initramfs-tools/modules as described in #803658 
("boot hangs before cryptsetup passphrase prompt if i915 drm driver is 
not in initramfs") has no effect.

- Pressing *any* key repeatedly is enough to eventually wake up the 
plymouth LUKS screen. For example, pressing Backspace many times.

Kind regards,

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

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

#60859 — Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

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

On Fri, 2018-05-04 at 12:20 +1200, Ben Caradoc-Davies wrote:
> On 04/05/18 11:52, Ben Caradoc-Davies wrote:
> > - Pressing *any* key repeatedly is enough to eventually wake up the 
> > plymouth LUKS screen. For example, pressing Backspace many times.
> 
> Even a modifier key is sufficient. Without input, the screen remains 
> blank indefinitely (with just a blinking cursor for "quiet" boot). 
> Pressing right Alt 11-18 times (varies from test to test) causes the 
> plymouth LUKS passphrase screen to appear.
> 
> I have attached a photo of the screen for a boot with "quiet" removed 
> from and "plymouth.debug" added to the kernel command line.

I wonder if this is related to the recent RNG changes.  It seems that
many programs have started using blocking RNG functions like
getentropy(), and now that the kernel is more conservative in its
initial entropy estimation they can block for a long time.  Keyboard or
mouse input adds entropy.

At a guess, plymouth is starting the X server and the X server wants
random bits for MIT-MAGIC-COOKIE authentication.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
                                                         - Albert Camus

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

#60863 — Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

On 06/05/18 07:01, Ben Hutchings wrote:
> I wonder if this is related to the recent RNG changes.  It seems that
> many programs have started using blocking RNG functions like
> getentropy(), and now that the kernel is more conservative in its
> initial entropy estimation they can block for a long time.  Keyboard or
> mouse input adds entropy.
> At a guess, plymouth is starting the X server and the X server wants
> random bits for MIT-MAGIC-COOKIE authentication.

Ben, I think you might be right. Only a few mouse wiggles are sufficient 
to trigger the appearance of the plymouth LUKS screen. I guess that 
mouse activity is a richer source of entropy than key presses.

So, where to from here? Should this be reassigned to plymouth or xorg?

Kind regards,

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

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

#60866 — Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

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

On Sun, 2018-05-06 at 12:33 +1200, Ben Caradoc-Davies wrote:
> On 06/05/18 07:01, Ben Hutchings wrote:
> > I wonder if this is related to the recent RNG changes.  It seems that
> > many programs have started using blocking RNG functions like
> > getentropy(), and now that the kernel is more conservative in its
> > initial entropy estimation they can block for a long time.  Keyboard or
> > mouse input adds entropy.
> > At a guess, plymouth is starting the X server and the X server wants
> > random bits for MIT-MAGIC-COOKIE authentication.
> 
> Ben, I think you might be right. Only a few mouse wiggles are sufficient 
> to trigger the appearance of the plymouth LUKS screen. I guess that 
> mouse activity is a richer source of entropy than key presses.
> 
> So, where to from here? Should this be reassigned to plymouth or xorg?

Now that I've looked, it appears that Xorg is actually still using
/dev/urandom (via arc4random_buf() in libbsd).  So far as I know, reads
from /dev/urandom have historically succeeded without blocking, even
when there is very little entropy available.  Since many daemons depend
on this I think it has to be maintained.

But so far as I can see from the kernel code, that hasn't changed -
only the newer getentropy() function is more likely to block.  So I'm
quite confused.

Ben.

-- 
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.

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

#60873 — Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

On Sat, 05 May 2018 20:01:45 +0100 Ben Hutchings <ben@decadent.org.uk> 
wrote:
 > On Fri, 2018-05-04 at 12:20 +1200, Ben Caradoc-Davies wrote:
 > > On 04/05/18 11:52, Ben Caradoc-Davies wrote:
 > > > - Pressing *any* key repeatedly is enough to eventually wake up the
 > > > plymouth LUKS screen. For example, pressing Backspace many times.
 > >
 > > Even a modifier key is sufficient. Without input, the screen remains
 > > blank indefinitely (with just a blinking cursor for "quiet" boot).
 > > Pressing right Alt 11-18 times (varies from test to test) causes the
 > > plymouth LUKS passphrase screen to appear.
 > >
 > > I have attached a photo of the screen for a boot with "quiet" removed
 > > from and "plymouth.debug" added to the kernel command line.
 >
 > I wonder if this is related to the recent RNG changes. It seems that
 > many programs have started using blocking RNG functions like
 > getentropy(), and now that the kernel is more conservative in its
 > initial entropy estimation they can block for a long time. Keyboard or
 > mouse input adds entropy.
 >
 > At a guess, plymouth is starting the X server and the X server wants
 > random bits for MIT-MAGIC-COOKIE authentication.

Hello Ben,

plymouth doesn't uses Xorg, it uses libdrm and KMS directly.

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

#60878 — Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

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

On Sun, 2018-05-06 at 17:22 +0200, Laurent Bigonville wrote:
> On Sat, 05 May 2018 20:01:45 +0100 Ben Hutchings <ben@decadent.org.uk> 
> wrote:
>  > On Fri, 2018-05-04 at 12:20 +1200, Ben Caradoc-Davies wrote:
>  > > On 04/05/18 11:52, Ben Caradoc-Davies wrote:
>  > > > - Pressing *any* key repeatedly is enough to eventually wake up the
>  > > > plymouth LUKS screen. For example, pressing Backspace many times.
>  > >
>  > > Even a modifier key is sufficient. Without input, the screen remains
>  > > blank indefinitely (with just a blinking cursor for "quiet" boot).
>  > > Pressing right Alt 11-18 times (varies from test to test) causes the
>  > > plymouth LUKS passphrase screen to appear.
>  > >
>  > > I have attached a photo of the screen for a boot with "quiet" removed
>  > > from and "plymouth.debug" added to the kernel command line.
>  >
>  > I wonder if this is related to the recent RNG changes. It seems that
>  > many programs have started using blocking RNG functions like
>  > getentropy(), and now that the kernel is more conservative in its
>  > initial entropy estimation they can block for a long time. Keyboard or
>  > mouse input adds entropy.
>  >
>  > At a guess, plymouth is starting the X server and the X server wants
>  > random bits for MIT-MAGIC-COOKIE authentication.
> 
> Hello Ben,
> 
> plymouth doesn't uses Xorg, it uses libdrm and KMS directly.

Oh I see, I was confused by the existence of plymouth-x11.

Ben.

-- 
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.

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

#60864 — Bug#897572: plymouth: long delay before splashscreen with kernel 4.16

Looks like the same bug. We should probably merge, but into what package 
(linux, plymouth, or xorg)?:

Bug#897958: plymouth: long delay before splashscreen with kernel 4.16
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897958

Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572

Ben Hutchings suggests that this is probably caused by the new RNG 
behaviour in 4.16, and I concur. See Ben's remarks in #897572 
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572>.

Kind regards,

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

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

#60870 — Bug#897572: plymouth: long delay before splashscreen with kernel 4.16

You are right. Seems to be the same bug. I thought that since everything 
works fine without plymouth that it should be fixed there but now I am 
not sure anymore. Also I'm not so familiar with debian bug tracker. Can 
or should I mark it as duplicate somehow or merge it with your bug report?


Am 06.05.2018 um 03:01 schrieb Ben Caradoc-Davies:
> Looks like the same bug. We should probably merge, but into what 
> package (linux, plymouth, or xorg)?:
>
> Bug#897958: plymouth: long delay before splashscreen with kernel 4.16
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897958
>
> Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572
>
> Ben Hutchings suggests that this is probably caused by the new RNG 
> behaviour in 4.16, and I concur. See Ben's remarks in #897572 
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572>.
>
> Kind regards,
>

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

#60888 — Bug#897572: plymouth: long delay before splashscreen with kernel 4.16

Ben,

even though X is not involved, you are right on the money about this 
being caused by waiting for random bits. This is a kernel bug caused by 
urandom blocking when it should not. I will merge the issues when I have 
my final patch ready.

You can see the "random: plymouthd: uninitialized urandom read" warning 
in my screen photo:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=897572;filename=img_20180504_120059.jpg;msg=37

This bug is introduced by the "crng_init > 0" to "crng_init > 1" change 
in this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43838a23a05fbd13e47d750d3dfd77001536dd33

This change inadvertently impacts urandom_read, causing the crng_init==1 
state to be treated as uninitialized and causing urandom to block, 
despite this state existing *specifically* to support non-cryptographic 
needs at boot time:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n1863

Reverting 43838a23a05f ("random: fix crng_ready() test") fixes the bug 
(tested with 4.16.5-1), but this may cause security concerns 
(CVE-2018-1108 is mentioned in 43838a23a05f). I am testing a more 
localised fix that should be more palatable to upstream.

Kind regards,

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

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

#60876 — Bug#897572:

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

FWIW, I have the exact same problem (and can resolve it the exact same way,
by moving my finger over my trackpad for a few seconds), and am on a
different graphics card -- Intel Iris Graphics 540 (Skylake GT3e).

I'm not an expert in kernel/firmware stuff at all, and can't compile a
kernel from scratch, but let me know if there's anything I can pull from my
system that would be useful in diagnosing the issue.

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

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

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.

See:

urandom 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>
---
 drivers/char/random.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index cd888d4ee605..cae3249ecdef 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -428,7 +428,7 @@ struct crng_state primary_crng = {
  * its value (from 0->1->2).
  */
 static int crng_init = 0;
-#define crng_ready() (likely(crng_init > 1))
+#define crng_ready() (likely(crng_init > 0))
 static int crng_init_cnt = 0;
 static unsigned long crng_global_init_time = 0;
 #define CRNG_INIT_CNT_THRESH (2*CHACHA20_KEY_SIZE)
@@ -843,7 +843,7 @@ static int crng_fast_load(const char *cp, size_t len)
 
 	if (!spin_trylock_irqsave(&primary_crng.lock, flags))
 		return 0;
-	if (crng_init != 0) {
+	if (crng_ready()) {
 		spin_unlock_irqrestore(&primary_crng.lock, flags);
 		return 0;
 	}
@@ -963,7 +963,7 @@ static void _extract_crng(struct crng_state *crng,
 {
 	unsigned long v, flags;
 
-	if (crng_ready() &&
+	if (crng_init > 1 &&
 	    (time_after(crng_global_init_time, crng->init_time) ||
 	     time_after(jiffies, crng->init_time + CRNG_RESEED_INTERVAL)))
 		crng_reseed(crng, crng == &primary_crng ? &input_pool : NULL);
@@ -1245,7 +1245,7 @@ void add_interrupt_randomness(int irq, int irq_flags)
 	fast_mix(fast_pool);
 	add_interrupt_bench(cycles);
 
-	if (unlikely(crng_init == 0)) {
+	if (!crng_ready()) {
 		if ((fast_pool->count >= 64) &&
 		    crng_fast_load((char *) fast_pool->pool,
 				   sizeof(fast_pool->pool))) {
@@ -2314,7 +2314,7 @@ void add_hwgenerator_randomness(const char *buffer, size_t count,
 {
 	struct entropy_store *poolp = &input_pool;
 
-	if (unlikely(crng_init == 0)) {
+	if (!crng_ready()) {
 		crng_fast_load(buffer, count);
 		return;
 	}
-- 
Ben Caradoc-Davies <ben@transient.nz>
Director
Transient Software Limited <https://transient.nz/>
New Zealand

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

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

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

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

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

On 07/05/18 15:29, Theodore Y. Ts'o wrote:
> 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.

Thanks, Ted. I agree with your concerns. I tried to fix urandom to work 
when crng_init==1 but did not want to touch common code and risk 
reverting the security fixes.

Laurent, is there a workaround in plymouth space? Why does plymouth need 
random numbers?

Kind regards,

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

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

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

By the way, if anyone is interested in working on this related
problem:

   https://news.ycombinator.com/item?id=16976421

   The reason why this is hard is because Linux is supported on a
   great number of architectures, and some architectures have more
   than one boot loader that is used. The approach of letting the
   bootloader pass seed entropy is the right answer in general, I
   agree, but unlike OpenBSD we can't assume that it will always be
   present. (OpenBSD only supports a limited number of architectures,
   and a single bootloader.) Hence, no matter what, we have to have
   fallback mechanisms for dealing with the case where we have a
   bootloader which doesn't pass a seed to the kernel.

   The other issue is that I don't get paid to work on the random
   driver in Linux. I've been looking for volunteers to work with the
   grub, syslinux, efistub, not to mention all of the various signed
   bootloaders used by different Android devices, but because we had a
   fallback mechanism there is less motivation for people to want to
   work on this.

   This would actually be a great intern project or GSOC project, but
   this have been so hectic this year, personally and professionally,
   I didn't have the time to commit to hosting an intern or GSOC
   student this summer. :-(

Send me an note, and let's talk.  :-)

     	   	     	   	  - Ted

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

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

Hello,

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.

Installing rng-tools5 seems to help in that case.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web