[solved] Delay von bis zu 2 Min. beim Login mit Kernel 4.9.88-1

[ingo2]

Seit dem (am 29.04.2018) erfolgtem Keren-Upgrade auf 4.9.88-1 habe ich einen gewaltigen Delay vom Login mit Lightdm bis zum Erscheinen des XFCE4-Desktops.

Auf dem Dektop PC mit Ivy-Bridge-CPU ist das nicht wirklich merklich, aber beim Laptop mit Sandy-Brige-CPU (T420/T520) kann die Verzögerung bis über 2 Minuten dauern. Mit dem alten 4.9.0-5 Kernel ist es nicht feststellbar.

Die Suche nach der Ursache auf dem Laptop ergab folgendes, was jeder einfach reproduzieren kann:

Code: Alles auswählen

cat /var/log/messages | grep crng

ergibt mit Kernel 4.9.0-5 durchschnittlich 15 - 18 sec., beim neuen Kernel dagegen bis zu 150 sec.!
(Beim Ivy-Bridge-Desktop sind's vorher 6s, jetzt 16s. das fällt kaum auf)

Es dauert offenbar jetzt viel länger bis genügend Entropie für Zufallszahlen gesammelt wurde. Das ist eindeutig dem letzten Kernel-Upgrade zuzuschreiben. Warum aber der Aufbau des XFCE-Desktops auf gültige Zufallszahlen warten muß, ist mir ein Rätsel. Habe schon viel zur Lösung ausprobiert, z.B. NetworkManager/WLAN+WPA2, ohne Erfolg, es passiert auch bei Ethernetanschluß.

Gibt es da eine saubere Lösung, außer auf den vorherigen Kernel zurückzugehen, z.B. Kernel- oder Modul-parameter?

EDIT:
die man-page

Code: Alles auswählen

man 4 urandom

gibt einen Hinweis und sogar 2 Scripte für boot und shutdown, um da was zu flicken - könnte das helfen?

[DeletedUserReAsG]

Ohne genaueres zum Problem selbst sagen zu können, aber wenn tatsächlich Entropie fehlt, könnte haveged einen Blick wert sein.

[ingo2]

... wenn tatsächlich Entropie fehlt, könnte haveged einen Blick wert sein.

Danke, einfach installiert - und der Delay ist weg.
Jetzt ist die Entropie nach 4sec. voll:

Code: Alles auswählen

[   3.906981] random: crng init done

Frage mich nur, wozu um Himmels Willen braucht der Desktop unbedingt Entropie?
Daß es an Entropie fehlte, ist ja hiermit wohl bewiesen.

EDIT:
Noch etwas Info dazu:
Das Arch-Wiki hat einen guten Artikel zu haveged https://wiki.archlinux.org/index.php/Ra ... generation.
Habe das jetzt mal an meimem Laptop getestet mit

Code: Alles auswählen

cat /proc/sys/kernel/random/entropy_avail

Der hatte ohne havedeg direkt nach dem Login nur "250", was dann im laufe der Zeit bis auf "850" anstieg.
Nach der Installation von havedeg liegt der Wert so um die "2500", also Faktor 3.
Das ist dann ok. Ich nehme an, die Zahlen sind random-Bytes im Pool, die bei vollem Puffer "4096" sind?

[ingo2]

So, jetzt habe ich die Wurzel des Übels gefunden:

Intel CPU's haben seit Ivy-Bridge einen Hardware-Random-Generator (mein Desktop-PC), die Laptops haben Sandy-Bridge-CPU's ohne HWRNG! Da hift dann nur noch haveged.

Und daß das ganze jetzt erst Auswirkungen hat, liegt meier Meinung nach an den Patches gegen Spectre und Meltdown.

[ingo2]

Und jetzt noch weitere Info/Hintergrund:

Habe mal das zugehörige changlog von hier https://tracker.debian.org/media/packag ... g-4.9.88-1 angeschaut. Suche nach "random" vom Anfang findet folgende Änderung:

Code: Alles auswählen

  * random: fix crng_ready() test (CVE-2018-1108)
  * random: set up the NUMA crng instances after the CRNG is fully initialized
  * random: crng_reseed() should lock the crng instance that it is modifying
  * random: fix possible sleeping allocation from irq context

Es wird jetzt also der Bootvorgang angehalten bis crng den Pool ausreichend gefüllt hat. Das war offenbar bisher nicht der Fall und hat zu CVE-2018-1108 geführt. Die Info dazu findet sich bei RedHat als https://access.redhat.com/security/cve/cve-2018-1108.

Damit ist die Geschichte geklärt und es wird wohl nicht mehr zurückgenommen - mit der Folge, daß alte CPU's ohne HWRNG wohl ewig zum Booten brauchen werden. wenn man nicht den Pool auf andere Weise schneller füllt.

[slu]

Ohne genaueres zum Problem selbst sagen zu können, aber wenn tatsächlich Entropie fehlt, könnte haveged einen Blick wert sein.

Genau das selbe Problem habe ich auch auf ein paar Maschinen, haveged hat es gelöst.
Vielen Dank für den Hinweis!

Übrigens, es waren alles Gnome-Shell / gdm3 Rechner.
Schön bitter das so etwas nach einem Kernel Update passiert.

[slu]

Heute gibt es ein Kernel Update:

Code: Alles auswählen

linux (4.9.88-1+deb9u1) stretch-security; urgency=high
[...]
  * Revert "random: fix crng_ready() test" (Closes: #897599), reopening
    CVE-2018-1108

[ingo2]

Jepp, mit diesem "neuen" Kernel ist der Delay wieder weg - und CVE-2018-1108 wieder da

Ich habe durch Versuche und Monitoring der Entropie noch folgendes beobachtet:

a) Auch auf meinem Ivy-Bridge-PC kann ich das Phänomen nachstellen, wenn ich während des Bootens weder Maus noch Tastatur benutze. Beim Login dann nur mein Passwort tippen, sonst nichts. Dann dauert auch dort der Aubau des Dektops lange und der Timestamp für crng init done beträgt 29 sec. (normal sind's nur 16-18). Tastatur und Maus erzeugen schnell die nötige Entropie (1x Mahjongg gespielt bringt 3000 bit).
Daraus folgt, daß der Kernel nicht den HWRNG der CPU benutzt, sondern wie in der Urzeit selbst Entropie sammelt.

b) die Schwelle für "genug Entropie" (bei Kernel 4.9.88-1) scheint bei ca. 256 bit zu liegen, erst dann geht es weiter. Laut Wikipedia benötigt der Start eines jeden Prozesses 16 bit Entropie, deshalb ist irgendwann Schluß, je nachdem wie viele Prozesse nach Reboot gestartet werden sollen.

c) Und das ist wohl dann auch der "Fluch" von systemd, der jetzt in wenigen Sekunden alle Prozesse starten will, was natürlich dann zu Problemen führt, wie die Debian-Bugs 897599, 897632 und 897917 zeigen.

Die Lösung wäre doch wirklich, einen vorhandenen HWRNG zu nutzen (rng-tools), falls diese ordentliche Qualität haben?

[KBDCALLS]

Das ist ziemlich lustig. Ich habe das Problem das der Xserver ewig braucht bis er startet. Mit Kernel 4.16.5-1. Desktop ist KDE/Plasma Und sddm. Hat also das gleiche Problem. Intel ist wohl auch nicht mehr das was es mal war. Hauptsache schnell Kohle machen, alles andere ist zweitrangig.

Code: Alles auswählen

matthias@hannelore:~$ inxi --cpu
CPU:       Topology: Quad Core model: Intel Core i5-4570 bits: 64 type: MCP L2 cache: 6144 KiB 
           Speed: 3194 MHz max: 3600 MHz Core speeds (MHz): 1: 3195 2: 3195 3: 3193 4: 3193


inxi -M
Machine:   Type: Desktop Mobo: Intel model: DH87RL v: AAG74240-401 serial: N/A BIOS: Intel 
           v: RLH8710H.86A.0317.2013.0426.1724 date: 04/26/2013

[ingo2]

Hauptsache schnell Kohle machen, alles andere ist zweitrangig.

Code: Alles auswählen

matthias@hannelore:~$ inxi --cpu
inxi -M
Machine:   Type: Desktop Mobo: Intel model: DH87RL v: AAG74240-401 serial: N/A BIOS: Intel 
           v: RLH8710H.86A.0317.2013.0426.1724 date: 04/26/2013

Habe hier auch ein Intel DH77EB-MoBo mit Ivy-Bridge-CPU. Letztes BIOS stammt auch von 2013.
Aber wenigstens habe ich das Microcode-Update für die CPU installiert:

Code: Alles auswählen

ii  intel-microcode                     3.20180425.1~bpo9+1

muß man aber manuell anstoßen, da es in "non-free" ist.

[ingo2]

Genau das selbe Problem habe ich auch auf ein paar Maschinen, haveged hat es gelöst.
Vielen Dank für den Hinweis!

Übrigens, es waren alles Gnome-Shell / gdm3 Rechner.
Schön bitter das so etwas nach einem Kernel Update passiert.

Auch dazu gibt es einen Bug-Report 897631. Der war ursprünglich auch dem Entropie-Problem zugeordnet, wurde dann aber abgetrennt. Da muß sicher das Gnome-Team noch Arbeit reinstecken, denn so böse darf das wirklich nicht abstürzen, nur weil Entropie fehlt.
Aber gerade die Gnome-Leute mißbrauchen ja systemd massiv für ihren Desktop, obwohl das eigentlich dem System (ursprünglich nur) als Init-System vorbehalten war und beim logind Schluß sein sollte