Dear Maintainer,

kernel 4.16 on debian testing is causing an infinite wait after the FIRST
display manager authentication.

clicking the mouse buttons alternately L-R-L-R sometimes ceases it. subsequent
authentications are good. rebooting repeats it.
tested with lightdm and xdm, and xfce and lxqt.

seen on yvy bridge and bay trail systems using integrated intel graphics. ok on
dicrete nvidia graphics using the vendor driver, and old GMA3000 and N550
(pineview) systems.

all fine when booting 4.15.

Dear Maintainer,

I also seem to have this issue. After upgrading my kernel to linux-image-4.16.0-1-amd64,
the graphical login screen (sddm) either is not shown or only shown after a delay
(>10s after I complete the text mode login). Before the upgrade X would start instantly.
Clicking the mouse does not seem to have an effect with my setup.

Booting the previous kernel, linux-image-4.15.0-3-amd64, does not exhibit this problem.
After booting linux-image-4.16.0-1-amd64, starting X from the tty (startkde in my case),
works too.

I can provide additional details if helpful.

Sten

I'm seeing this on a few laptops with SSD's.

The behaviour is that if the device isn't interacted with in any way, the
machines hang for 2-4 mins at boot.

Seems to be related to the fix for CVE-2018-1108 - random: fix crng_ready()
test

https://security-tracker.debian.org/tracker/CVE-2018-1108

Pedro & Sten, can you try introducing entropy into the systems affected
when they appear to hang, to see if this reduces the delays?

eg: moving the mouse, tapping shift/ctrl/alt keys, pinging the device on
the network if network is already up, etc?

I suspect this bug can be merged with 897599, 897632 and 897917.

Hi Stuart,
I guess it is related, just moving the mouse will indeed bypass the
"freeze", but there is always some delay (4-5 sec) in which the desktop
will wait. And it does happen on SSD-only laptops: a Bay Trail (Celeron)
and a Ivy Bridge (i3), but not on a Pineview (Atom), this last one has a 32
bit install.

Pedro

Hi Stuart,

I definitely experience a much shorter delay if I press keys on the keyboard vs. doing nothing; the delay decreases from >5 minutes to 10-20 seconds before sddm appears.

Sten

My workarounds for this at the moment are to install tools that increase
the kernel entropy pool.

If not a virtual machine, and `grep -i -o -m 1 rdrand /proc/cpuinfo`
returns 'rdrand', then I install the 'rng-tools5' package which uses the
hardware rng in many cpu's to provide entropy to the kernel.

If that fails or if it's a virtual machine, then I install the 'haveged'
package.

Note: Neither of these are fixes. They're work-arounds for the current
issue that allow somewhat normal operation. eg; Some people have issues
around how random the hardware rng is in some machines.

PS: Have seen a number of people suffering this issue in #debian on
freenode, and also on #debian & #debian-next on oftc.

Any news to fix this behavior?


Greetings...

The bug causing (at least some) problems with starting GUIs is #898088;
that's not a kernel bug.

Ben.

Am 20.05.2018 um 16:30 schrieb Ben Hutchings:
The Patch from #898088 for me not helps, same problem (J1900 bay trail).


Holger...

Am 20.05.2018 um 16:30 schrieb Ben Hutchings:
Hi.

Any News? For me is this not fixed, my Intel Celereon J1900 (Bay Trail)
very long Delay. Same with 4.16.0-2-amd64.

With Kernel 4.15.0 no Problems.

Thanks...

Meanwhile my Debian Testing systems have (per default) upgraded to libbsd
0.9.1 (and kernel 4.16.0-2). Unfortunaetly, this does not fix the problem
(long ssdm start) under virtualization by kvm, although according to #898088
libvirt 0.9.0-1 should have alredy fixed this.

On productive bare metal I cannot say anything, as I have set kernel 4.16 on
hold by apt.

Thx, Chris

I can confirm libbsd0 0.9.1-1/bug #898088 does not fix my problems, and neither does upgrading to linux-image-4.16.0-2-amd64.

(Btw. this is on a Skylake CPU.)

Sten

On Mon, 7 May 2018 06:40:36 +0200 "Sten Heinze" <shze@gmx.de> wrote:> I definitely experience a much
shorter delay if I press keys on the keyboard vs. doing nothing; the delay decreases from >5 minutes
to 10-20 seconds before sddm appears.

Yes! I have same problem, thought not with 4.16, but with 4.17. If I login via full screen terminal,
sddm starts after some seconds, without managing me to enter password second time for `sudo -i` (to
check logs or whatever).

Very strange bug indeed.

Maxy (KDE/sddm maintainer) just suggested me to use haveged to workaround the
issue.

From the Qt/sddm code this would certainly not affect security, as the problem
lies in a hash structure used in the code. I can not vouch for other stuff in
the machine.

I have not seen this bug so far, but if any of you can still reproduce it you
might want to give this a try.

Cheers, Lisandro.

the
problem
stuff in
you

I've experienced it just today while installing Buster on an old Kentsfield
system, so it's still present on kernel 4.16.
I have used haveged to just forget about it, more entropy won't hurt when
it's fixed.

Cheers.
Pedro

Thiago Maciera, the developer in charge of QHash, also works at Intel and made
some points which you might find interesting.

From https://bugreports.qt.io/browse/QTBUG-69555

  If the machine is question is virtual: make sure the host exports a virtual
  HWRNG for the guest to use. VMs will not collect enough entropy fast enough
  otherwise.

  You should consider using an entropy collector to reseed at boot. See
  haveged.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898021 talks about a
  problem on IVB, but IVB has a hardware RNG. Is this really a cold boot?

https://wiki.qemu.org/index.php/Features/VirtIORNG
  and https://wiki.qemu.org/Features/Real_rng_device

Regards, Lisandro.

Thiago Maciera, the developer in charge of QHash, also works at Intel and made
some points which you might find interesting.

From https://bugreports.qt.io/browse/QTBUG-69555

  If the machine is question is virtual: make sure the host exports a virtual
  HWRNG for the guest to use. VMs will not collect enough entropy fast enough
  otherwise.

  You should consider using an entropy collector to reseed at boot. See
  haveged.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898021 talks about a
  problem on IVB, but IVB has a hardware RNG. Is this really a cold boot?

https://wiki.qemu.org/index.php/Features/VirtIORNG
  and https://wiki.qemu.org/Features/Real_rng_device

Regards, Lisandro.

[...]

I don't think this is correct.  The Linux RNG doesn't really trust
entropy provided by HWRNGs.

More background information:
https://lists.debian.org/debian-release/2018/05/msg00130.html
https://lists.debian.org/debian-release/2018/05/msg00176.html

Ben.

[...]

I don't think this is correct.  The Linux RNG doesn't really trust
entropy provided by HWRNGs.

More background information:
https://lists.debian.org/debian-release/2018/05/msg00130.html
https://lists.debian.org/debian-release/2018/05/msg00176.html

Ben.

This has happened so far:

From the Debian side maxy added haveged as a sddm recommendation and as a
workaround.

From the Qt side Thiago from upstream is trying to determine what changed in
the kernel side, as this clearly started to happen with 4.16 and got worse
with 4.17.

Ben, linux maintainers: if you could give us a hand to determine what changed
from the kernel side it would be much much appreciated. If we find that there
are valid changes then we might have an opportunity to make Qt upstreams
reconsider the issue.

Cheers, Lisandro.

CVE-2018-1108 was fixed in the kernel.

Ben.

Thanks Ben!!!!

This is not really fixed in linux-image-4.17.0-1-amd64.

I'm still having a little delay with 4.17.8-1.


Holger...

Hi Holger!

El jue., 26 de jul. de 2018 13:18, Holger Schröder <Holgi.HSP@gmx.de>
escribió:



It should not. The kernel now takes more time to get the necessary entropy
(actually before it was giving random values when it shouldn't).

A workaround is to install haveged, but beware that some people don't trust
it enough.

For what I've saw having an encrypted disk helps.

Regards, Lisandro

Am 26.07.2018 um 22:38 schrieb Lisandro Damián Nicanor Pérez Meyer:

I have install rng-tools5 to solve the problem.

No delay with this.


Holger...