Entropie unter Linux: urandom und haveged fuer schnelle PHP-Sessions

1. Warum Entropie-Mangel Requests unsichtbar verzoegert

Wer Performance-Probleme bei Magento-Servern untersucht, prueft in aller Regel zuerst CPU, Arbeitsspeicher, Disk-I/O und Netzwerk. Die Qualitaet des Zufallszahlengenerators gehoert selten zu den ersten Verdaechtigen, obwohl sie in bestimmten Umgebungen eine ebenso reale Ursache fuer Latenz sein kann wie jede dieser klassischeren Metriken.

Jede kryptographisch sichere Zufallszahl, die eine Anwendung unter Linux anfordert, sei es fuer eine Session-ID, einen CSRF-Token oder den Schluesselaustausch bei einem TLS-Handshake, stammt letztlich aus dem Entropie-Pool des Kernels. Dieser Pool wird kontinuierlich aus unvorhersehbaren Ereignissen gespeist: Interrupt-Timing, Festplattenzugriffe, Netzwerkpakete und, auf physischer Hardware, Maus- und Tastaturbewegungen. Reicht die gesammelte Entropie nicht aus, kann ein Zufallszahlen-Aufruf ins Blockieren geraten, bis genuegend neue Entropie gesammelt wurde.

In sicherheitskritischen Kontexten wie Zahlungsabwicklung und Authentifizierung ist eine belastbare Zufallszahlenquelle ohnehin nicht verhandelbar. Die hier beschriebenen Massnahmen adressieren deshalb ausschliesslich die Performance-Seite dieses Themas, ohne die kryptographische Staerke der erzeugten Zufallsdaten zu beeintraechtigen.

Fuer einen Magento-Webserver bedeutet das: PHP ruft bei jedem session_start() und bei jeder Verwendung von random_bytes() intern eine Kernel-Funktion auf, die Zufallsdaten liefert. Auf einem gut ausgelasteten Bare-Metal-Server mit vielfaeltigen Interrupt-Quellen ist Entropie-Mangel selten ein Problem, weil der Pool durch die natuerliche Systemaktivitaet konstant aufgefuellt wird. Auf frisch gestarteten virtuellen Maschinen oder in minimalen Container-Images sieht die Situation dagegen vollstaendig anders aus.

Das tueckische an Entropie-Mangel ist seine Unsichtbarkeit in klassischen Performance-Metriken: Die CPU-Auslastung bleibt niedrig, die Netzwerkverbindung ist nicht ausgelastet, und trotzdem haengt ein Request scheinbar grundlos fuer einige hundert Millisekunden bis wenige Sekunden. Erst eine gezielte Untersuchung des Entropie-Pool-Fuellstands deckt in solchen Faellen die tatsaechliche Ursache auf.

2. /dev/random, /dev/urandom und getrandom() im Vergleich

Diese Unterscheidung sorgt in der Praxis regelmaessig fuer Verwirrung, insbesondere weil aeltere Tuning-Ratgeber teils veraltete Empfehlungen zu /dev/random enthalten, die auf modernen Kernel-Versionen nicht mehr zutreffen.

Um die richtige Wahl fuer die eigene Umgebung zu treffen, hilft ein kurzer Blick zurueck auf die historische Entwicklung dieser Schnittstellen.

Historisch bot Linux zwei Zufallszahlengeneratoren als Geraetedateien an: /dev/random, das blockiert, sobald der geschaetzte Entropie-Vorrat des Kernels erschoepft ist, und /dev/urandom, das nach der initialen Kernel-Startphase praktisch nie blockiert, weil es einen kryptographisch sicheren Pseudozufallszahlengenerator (CSPRNG) verwendet, der einmal mit ausreichend Entropie initialisiert wurde. Fuer nahezu alle Anwendungsfaelle, einschliesslich kryptographischer Schluessel, gilt /dev/urandom seit Jahren als die richtige Wahl, da moderne CSPRNGs auch mit begrenzter initialer Entropie kryptographisch starke Ausgaben liefern.

Seit Linux-Kernel-Version 3.17 existiert zusaetzlich der Systemaufruf getrandom(), den moderne PHP-Versionen fuer random_bytes() und random_int() intern nutzen. getrandom() blockiert nur einmalig, direkt nach dem Systemstart, bis der Kernel-CSPRNG initial mit ausreichend Entropie geseedet wurde, und liefert danach ohne weitere Blockierung Zufallsdaten. Genau diese einmalige Initialisierungsphase ist der kritische Moment, in dem ein frisch gestarteter Server oder Container unerwartet haengen bleiben kann, wenn keine ausreichend schnelle Entropie-Quelle zur Verfuegung steht.

# Check the current entropy pool size the kernel considers available
cat /proc/sys/kernel/random/entropy_avail

# On modern kernels this typically reports a high value (thousands)
# once the CSPRNG has been fully seeded after boot

3. Wie der Kernel Entropie sammelt

Ein grundlegendes Verstaendnis dieser Sammlungsmechanismen erklaert, warum manche Server-Klassen strukturell anfaelliger fuer Entropie-Mangel sind als andere, unabhaengig von der konkreten Linux-Distribution oder Kernel-Version.

Diese Sammlung erfolgt vollstaendig automatisch und ohne Zutun des Administrators, solange geeignete Quellen ueberhaupt vorhanden sind, was den naechsten Abschnitt zur zentralen Frage macht.

Der Kernel sammelt Entropie aus mehreren unabhaengigen Quellen und mischt sie in einen internen Pool. Auf physischer Hardware liefern Interrupt-Timing von Festplatten, Netzwerkkarten und, bei Desktop-Systemen, Eingabegeraete einen kontinuierlichen Strom an unvorhersehbaren Ereignissen. Moderne CPUs bringen zudem oft eine Hardware-Zufallszahlenquelle mit, etwa die RDRAND-Instruktion auf x86-Prozessoren, die der Kernel als zusaetzliche, sehr schnelle Entropie-Quelle nutzen kann, sofern sie als vertrauenswuerdig eingestuft wird.

Diese Luecke ist der eigentliche Ausgangspunkt fuer die in den folgenden Abschnitten beschriebenen Werkzeuge, die genau diese fehlenden Quellen kompensieren sollen.

Bei Servern ohne physische Eingabegeraete und ohne rotierende Festplatten, wie es bei den meisten Cloud-Instanzen und dedizierten Servern mit reinem SSD/NVMe-Storage der Fall ist, fallen zwei traditionell wichtige Entropie-Quellen komplett weg. Der Kernel ist dann staerker auf Netzwerk-Interrupt-Timing und, falls vorhanden, eine Hardware-RNG-Instruktion angewiesen, um seinen Pool zu fuellen, was in bestimmten Konstellationen zu einer spuerbar langsameren initialen Befuellung fuehren kann.

4. Warum VMs und Container besonders betroffen sind

Diese Anfaelligkeit betrifft nicht nur den initialen Boot-Vorgang, sondern kann sich bei jedem Neustart, jedem automatischen Skalierungsereignis und jedem Deployment eines neuen Images erneut zeigen, solange keine zusaetzliche Entropie-Quelle konfiguriert ist.

Virtuelle Maschinen sind fuer Entropie-Probleme besonders anfaellig, weil der Hypervisor viele der physischen Hardware-Interrupts, aus denen ein Bare-Metal-System seine Entropie schoepft, entweder gar nicht durchreicht oder in einer Form virtualisiert, die weniger unvorhersehbares Timing liefert. Ein frisch gebooteter Cloud-Server kann deshalb in den ersten Sekunden nach dem Start einen spuerbar langsameren Zugriff auf kryptographisch sichere Zufallsdaten haben als ein vergleichbares Bare-Metal-System, selbst wenn beide denselben Linux-Kernel nutzen.

Autoscaling-Gruppen in der Cloud sind hiervon besonders betroffen, da sie per Definition auf schnelles, wiederholtes Hochfahren neuer Instanzen ausgelegt sind, jede davon mit demselben potenziellen Entropie-Engpass in der Startphase.

Container verschaerfen dieses Problem tendenziell weiter, weil mehrere Container auf demselben Host typischerweise denselben Kernel-Entropie-Pool teilen und keine eigene, isolierte Entropie-Sammlung betreiben. Startet eine grosse Anzahl von PHP-FPM-Containern gleichzeitig, etwa nach einem Deployment oder einem automatischen Skalierungsereignis, und fuehrt jeder Container in der Startphase kryptographische Operationen aus, kann das kurzzeitig zu einer spuerbaren Verzoegerung fuehren, bis der gemeinsame Host-Pool ausreichend Entropie liefert.

5. Auswirkung auf PHP: Sessions, random_bytes und TLS

Diese Kette von Zufallszahlen-Anforderungen entsteht bei jedem einzelnen Checkout-Vorgang neu und ist deshalb kein einmaliges Randproblem, sondern eine wiederkehrende Belastung fuer den Entropie-Pool bei jedem neuen Kunden-Request.

PHP nutzt Zufallsdaten an mehreren kritischen Stellen: session_start() erzeugt eine neue Session-ID mit kryptographisch sicherem Zufall, random_bytes() und random_int() werden haeufig fuer CSRF-Token, Passwort-Reset-Links und API-Keys in Magento-Erweiterungen genutzt, und jeder TLS-Handshake, den ein PHP-Prozess als Client durchfuehrt, etwa beim Aufruf einer externen Zahlungs- oder Versand-API, benoetigt ebenfalls Zufallsdaten fuer den Schluesselaustausch.

Auch wiederkehrende Hintergrundprozesse wie das Versenden von Bestaetigungs-E-Mails ueber ein verschluesseltes SMTP-Relay oder der Abgleich mit einem externen Lagerbestandssystem koennen zusaetzliche TLS-Handshakes ausloesen, die denselben Entropie-Pool belasten wie die eigentliche Kundeninteraktion.

Bei einem Magento-Checkout-Prozess mit Zahlungsanbieter-Integration summieren sich diese Aufrufe: Session-Erzeugung beim ersten Seitenaufruf, CSRF-Token fuer das Bestellformular und ein ausgehender TLS-Handshake zum Zahlungsdienstleister koennen alle in kurzer Folge Zufallsdaten anfordern. Auf einem System mit ausreichend gefuelltem Entropie-Pool ist das vollstaendig unproblematisch, auf einem frisch gestarteten Container ohne zusaetzliche Entropie-Quelle koennen sich diese Aufrufe dagegen zu einer spuerbaren, wenn auch meist kurzen, Verzoegerung addieren.

6. haveged und rng-tools als Entropie-Quelle einrichten

Beide Werkzeuge sind seit Jahren in den Standard-Repositories aller gaengigen Linux-Distributionen verfuegbar und bringen in aller Regel sinnvolle Standardeinstellungen mit, sodass eine manuelle Feinjustierung nur in Ausnahmefaellen noetig ist.

haveged ist ein Daemon, der auf Basis von CPU-Timing-Variationen zusaetzliche Entropie generiert und dem Kernel-Pool zufuehrt, ohne auf physische Hardware-Interrupts angewiesen zu sein. Fuer Server ohne Maus, Tastatur und rotierende Festplatten ist haveged eine der einfachsten und zuverlaessigsten Loesungen, um den Entropie-Pool auch ohne diese klassischen Quellen konstant gut gefuellt zu halten. Die Installation ist auf den meisten Distributionen denkbar einfach und erfordert keine weitere Konfiguration fuer den Standardbetrieb.

Fuer die meisten Magento-Hosting-Umgebungen ohne spezielle Compliance-Anforderungen an die Zufallsquelle reicht haveged als alleinige Massnahme vollstaendig aus und stellt in der Praxis die mit Abstand am haeufigsten gewaehlte Loesung dar.

Alternativ oder ergaenzend kann rng-tools mit dem Daemon rngd eingesetzt werden, der Hardware-Zufallszahlenquellen wie RDRAND oder ein Trusted-Platform-Module (TPM) direkt in den Kernel-Pool einspeist. Auf Servern mit einer entsprechenden Hardware-RNG-Quelle ist dieser Ansatz oft die bevorzugte Wahl, weil er echte Hardware-Zufallszahlen nutzt, statt sie aus CPU-Timing-Variationen abzuleiten.

# Install and enable haveged as an additional entropy source
sudo apt-get install haveged
sudo systemctl enable --now haveged

# Verify it is running and check the resulting entropy pool level
systemctl status haveged
cat /proc/sys/kernel/random/entropy_avail

7. virtio-rng fuer virtuelle Maschinen nutzen

Wer eigene KVM-Hosts betreibt, sollte diese Konfiguration in die Standard-VM-Vorlage aufnehmen, damit jede neu erstellte virtuelle Maschine von Anfang an ueber eine zuverlaessige Entropie-Anbindung verfuegt, statt dies nachtraeglich pro Instanz nachruesten zu muessen.

Wichtig ist dabei die Unterscheidung zwischen dem Backend-Typ der virtio-rng-Konfiguration: /dev/random als Backend kann theoretisch auf dem Host blockieren, waehrend /dev/urandom als Backend, wie im folgenden Beispiel gezeigt, praktisch nie blockiert und deshalb fuer die meisten Setups die pragmatischere Wahl darstellt.

Fuer KVM-basierte virtuelle Maschinen bietet virtio-rng einen direkten, paravirtualisierten Kanal zur Entropie-Quelle des Host-Systems. Statt die Gast-VM auf eigene, oft unzureichende Entropie-Sammlung angewiesen sein zu lassen, leitet der Hypervisor Entropie vom Host, der in der Regel ueber ausreichend eigene Quellen verfuegt, direkt an den Gast weiter. Dies ist auf vielen Cloud-Plattformen bereits standardmaessig aktiviert, sollte aber bei selbst verwalteten KVM-Umgebungen explizit in der VM-Definition konfiguriert werden.

Fuer Xen-basierte Virtualisierung existiert ein aehnliches Konzept, und auch grosse Cloud-Anbieter stellen eigene virtualisierte Hardware-RNG-Schnittstellen bereit. Vor der Inbetriebnahme eines neuen VM-Images lohnt sich deshalb immer eine kurze Pruefung, ob eine virtualisierte RNG-Quelle bereits aktiv ist, bevor zusaetzlich haveged installiert wird, da beide Ansaetze sich zwar nicht gegenseitig ausschliessen, aber bei bereits vorhandenem virtio-rng oft redundant sind.

<!-- libvirt domain XML: add a virtio-rng device backed by /dev/urandom -->
<devices>
  <rng model="virtio">
    <backend model="random">/dev/urandom</backend>
  </rng>
</devices>

8. Entropie-Pool-Fuellstand ueberwachen

Ein dauerhaftes Monitoring dieser Kennzahl gehoert in dieselbe Kategorie wie die Ueberwachung von Load Average oder freiem Arbeitsspeicher: unauffaellig im Normalbetrieb, aber entscheidend fuer die schnelle Diagnose, wenn ein Problem tatsaechlich auftritt.

Idealerweise wird dieser Wert in ein bestehendes Monitoring-System wie Prometheus, Zabbix oder Nagios integriert, statt ihn nur manuell nach einem bereits aufgetretenen Problem zu pruefen.

Der einfachste Diagnoseschritt ist ein regelmaessiger Blick auf /proc/sys/kernel/random/entropy_avail, das die vom Kernel geschaetzte verfuegbare Entropie in Bits anzeigt. Ein dauerhaft niedriger Wert, insbesondere kurz nach einem Systemstart oder Container-Start, deutet auf ein potenzielles Problem hin und rechtfertigt die Einrichtung einer zusaetzlichen Entropie-Quelle wie haveged oder virtio-rng.

Ein sinnvoller Schwellenwert fuer eine Alarmierung liegt deutlich unterhalb der Werte, die ein gesundes System im Normalbetrieb aufweist, da kurzfristige Schwankungen normal sind und nicht jede kleine Absenkung sofort ein Eingreifen erfordert.

Fuer eine tiefergehende Diagnose lassen sich blockierende getrandom()-Aufrufe mit strace auf einem betroffenen PHP-FPM-Prozess sichtbar machen. Erscheint ein getrandom()-Aufruf in der Trace-Ausgabe mit einer auffaellig langen Laufzeit, ist das ein starkes Indiz fuer tatsaechliches Blockieren mangels ausreichender Entropie, statt einer anderen, unabhaengigen Ursache fuer die beobachtete Verzoegerung.

# Trace a specific PHP-FPM worker for blocking getrandom() calls
sudo strace -f -e trace=getrandom -T -p "$(pgrep -f 'php-fpm: pool' | head -1)"

# The -T flag shows the time spent in each syscall;
# an unusually long getrandom() call indicates entropy starvation

9. Loesungsansaetze im direkten Vergleich

Welcher Ansatz im Einzelfall passt, haengt weniger von persoenlicher Praeferenz ab als von der konkreten Infrastruktur: Bare-Metal-Server, KVM-VMs und Container-Hosts profitieren jeweils von unterschiedlichen Kombinationen dieser Werkzeuge.

Die folgende Tabelle vergleicht die gaengigen Ansaetze zur Behebung von Entropie-Mangel fuer unterschiedliche Server-Umgebungen.

Die Tabelle zeigt: Fuer virtualisierte und containerisierte Magento-Infrastrukturen ist eine explizite Entropie-Strategie kein optionales Detail, sondern eine sinnvolle Grundabsicherung gegen sporadische, schwer diagnostizierbare Latenzspitzen.

Fuer neue Server-Vorlagen empfiehlt sich deshalb, eine der genannten Loesungen von Anfang an in das Standard-Provisioning aufzunehmen, statt erst nach einem konkreten Vorfall reaktiv nachzuruesten. Ein einmal etabliertes Monitoring des Entropie-Fuellstands macht diese Entscheidung zudem jederzeit ueberpruefbar, ohne dass eine erneute manuelle Diagnose noetig waere.

Fuer Teams, die mehrere Magento-Instanzen auf unterschiedlicher Infrastruktur betreiben, von Bare Metal ueber KVM bis zu Container-Plattformen, lohnt sich eine einheitliche Richtlinie: welche Entropie-Loesung gilt als Standard fuer welchen Infrastruktur-Typ, und wie wird deren korrekte Funktion beim Server-Provisioning automatisiert verifiziert, statt sich auf eine einmalige manuelle Pruefung zu verlassen.

10. Zusammenfassung

Entropie-Mangel unter Linux ist eine der am schwersten zu diagnostizierenden Ursachen fuer sporadische Latenzspitzen, weil er in keiner der ueblichen Performance-Metriken auffaellt. /dev/urandom und der modernere Systemaufruf getrandom() sind fuer praktisch alle Anwendungsfaelle die richtige Wahl, koennen aber direkt nach dem Systemstart blockieren, wenn der Kernel-CSPRNG noch nicht ausreichend geseedet wurde, ein Effekt, der virtuelle Maschinen und Container besonders haeufig betrifft.

haveged liefert eine einfache, hardwareunabhaengige Loesung fuer Server ohne physische Entropie-Quellen, waehrend rng-tools echte Hardware-Zufallsquellen wie RDRAND nutzt und virtio-rng in KVM-Umgebungen direkten Zugriff auf die Host-Entropie ermoeglicht. Ein regelmaessiger Blick auf entropy_avail und gezielte strace-Diagnose auf blockierende getrandom()-Aufrufe helfen, das Problem zu erkennen, bevor es sich in schwer erklaerbaren Checkout-Verzoegerungen zeigt.

11. FAQ: Entropie unter Linux fuer PHP-Sessions