it-swarm.com.de

Was frisst meine Entropie? Oder was zeigt entropy_avail wirklich?

Unten finden Sie Diagramme mit dem Wert /proc/sys/kernel/random/entropy_avail Auf einem Raspberry Pi. Diese Antwort was möglicherweise nicht korrekt ist beschreibt es als:

/proc/sys/kernel/random/entropy_avail Gibt einfach die Anzahl der Bits an, die derzeit aus /dev/random Gelesen werden können. Versuche, mehr als das zu lesen, werden blockiert, bis mehr Entropie verfügbar wird.

Das Muster kommt immer zu dem gleichen "stabilen" Sägemuster mit einer Verringerung von ~ 130 Bit pro Minute. Wenn die Entropie zu stark wächst, "frisst" etwas sie, um in den Bereich von 700-800 zurückzukehren. Wenn ich das Gerät neu starte, wird die Entropie immer noch jede Minute verzehrt, jedoch in kleineren Stücken, sodass es wieder auf 700-800 wachsen kann.

Wie soll ich die Grafiken interpretieren? Was ist los?

Mein Gefühl ist, dass, wenn es nur einen Prozess mit einem Zufallszahlengenerator gab, der entropy_avail, Der einmal aus dem Gleichgewicht geraten ist (unter Verwendung der Gerätehardware), entweder unendlich wachsen oder auf das Niveau von 200 abfallen sollte, wenn /dev/random Würde die Werte nicht mehr liefern.

Auch wenn eine der Überwachungsmethoden (siehe Überprüfungen unten) die Entropie beeinflusst, sollte sie die Entropie lieber jede Sekunde verringern, anstatt sie in Intervallen von einer Minute plötzlich wachsen und fallen zu lassen.

(Wenn ich die Maschine im Leerlauf lasse, bleibt das stabile "Sägemuster" tagelang bestehen. Ich habe die Screenshots in kürzerer Zeit aufgenommen.)


Die Grafiken

  • Die Maschine ist lange im Leerlauf:

    (enter image description here

  • Gegen 19:14:45 Uhr wuchs ein anderer Computer, auf den apt-cacher Auf der Pi-Entropie zugegriffen wurde (ich denke aufgrund der Netzwerknutzung). Danach um 19:16:30 war der Abfall auf "übliche Werte" größer als üblich (es ist auch wiederholbar - wenn entropy_avail Zu groß wird, fällt er schneller ab):

    (enter image description here

  • Ich starte die Maschine neu, die Entropie wächst, bis sie das "übliche" Niveau erreicht:

    (enter image description here

    (enter image description here

  • Es erreicht wieder einen Ruhezustand:

    (enter image description here

  • Nach einem weiteren Neustart ändert sich der Zeitpunkt der Entropieverringerung, tritt jedoch immer noch jede einzelne Minute auf:

    (enter image description here


Überprüft

  • Ich habe netdata (Überwachungsprogramm) gestoppt und mit watch -n1 cat /proc/sys/kernel/random/entropy_avail Überprüft. Der Wert von entropy_avail Wächst auf ~ 800 und fällt in regelmäßigen Abständen von einer Minute auf ~ 680 ab.

  • Per Rat " Verfolge alle Prozesse für den Zugriff auf/dev/random und/dev/urandom" Ich habe mit inotifywait (Idee von einem Antwort auf eine ähnliche Frage) nachgefragt ) auf Debian VM und es gibt keinen Zugriff auf /dev/random oder /dev/urandom im Moment entropy_avail (natürlich überprüfen) protokolliert das Ereignis manuell).

  • Ich habe Entropie-Watcher verwendet, um die Entropie zu überprüfen, da davon abgeraten wurde, watch zu verwenden. Die Ergebnisse stimmen immer noch mit einem stetigen Anstieg und einem starken Abfall jede einzelne Minute überein:

    833 (-62)
    836 (+3)
    838 (+2)
    840 (+2)
    842 (+2)
    844 (+2)
    846 (+2)
    848 (+2)
    850 (+2)
    852 (+2)
    854 (+2)
    856 (+2)
    858 (+2)
    860 (+2)
    862 (+2)
    864 (+2)
    866 (+2)
    868 (+2)
    871 (+3)
    873 (+2)
    811 (-62)
    

Zwei Fragen zu Unix StackExchange, die dasselbe Phänomen beschreiben (später gefunden):

20
techraf

Erstens ist die Behauptung, dass "/proc/sys/kernel/random/entropy_avail einfach die Anzahl der Bits angibt, die derzeit aus /dev/random" gelesen werden können, falsch.

Das Feld entropy_avail liest input_pool.entropy_count , der "Ausgabe" -Pool bezieht sich auf den Pool, der für urandom (nicht blockierender Pool) und random (Blockierungspool).


Wie in diese Antwort erwähnt, verbraucht das Laichen neuer Prozesse Entropie für Dinge wie ASLR. Das Überwachungsprogramm erzeugt bei jedem Aufruf einen neuen Prozess. Möglicherweise führt das Überwachungstool dasselbe aus (möglicherweise über eine der anderen Überwachungsquellen, die ein externes Programm aufrufen müssen, um den Status zu erhalten?).

Um den Entropiepool zu überwachen, ohne ihn zu entleeren, können Sie das Entropie-Watcher-Programm ausprobieren (siehe verknüpfte Antwort).

Wenn Sie die entropy-watcher -Nummern genau beobachten, scheinen Sie in Intervallen etwa 64 Bit Entropie zu verlieren. Basierend auf der Analyse in der anderen Antwort scheint dies das Ergebnis der Verlagerung der Entropie in einen "Ausgabepool" zu sein, um eine Verschwendung zu vermeiden. Dies wird unter Linux v4.6 beobachtet. Zukünftige Implementierungen können unterschiedlich sein.

Basierend auf dem Quellcode (drivers/char/random.c in Version 4.6) kann ich sehen, dass das Lesen der Ausgabepools (/dev/{u,}random oder get_random_bytes()) extract_entropy{,_user} aufruft, der xfer_secondary_pool und account. Der Blockierungspool hat die Eigenschaft limit set (r->limit == 1), die beide Funktionen betrifft:

  • Für account() werden keine Daten aus dem Blockierungspool zurückgegeben, wenn die Entropie zu niedrig ist. Für den nicht blockierenden Ausgabepool wird die verbleibende Entropie verbraucht, es werden jedoch weiterhin Daten zurückgegeben.
  • xfer_secondary_pool() stellt sicher, dass im Ausgabepool genügend Entropie verfügbar ist. Wenn der blockierende Ausgabepool eine unzureichende Entropie aufweist, werden einige (wenn möglich) aus dem Eingabepool entnommen.
  • xfer_secondary_pool() für den nicht blockierenden Ausgabepool verhält sich speziell gemäß dem Parameter /proc/sys/kernel/random/urandom_min_reseed_secs. Wenn dieser Wert nicht Null ist, wird die Entropie nur dann aus dem Eingabepool entnommen, wenn seit der letzten Übertragung mindestens urandom_min_reseed_secs Sekunden vergangen sind. Standardmäßig ist dieser Wert auf 60 Sekunden eingestellt.

Der letzte Punkt erklärt schließlich, warum alle 60 Sekunden ein Entropie-Drain im Eingabepool angezeigt wird. Wenn ein Verbraucher zufällige Bytes aus dem nicht blockierenden Ausgabepool anfordert (TCP-Sequenznummern, ASLR, /dev/urandom, getrandom(), ...), werden 128 Bits vom Eingabepool an verbraucht Setzen Sie den nicht blockierenden Ausgabepool erneut ein.

8
Lekensteyn