Was entzieht Entropie?

Entropie geht nicht nur über /dev/{,u}random verloren , der Kernel nimmt auch etwas. Beispielsweise haben neue Prozesse randomisierte Adressen (ASLR) und Netzwerkpakete benötigen zufällige Sequenznummern. Sogar das Dateisystemmodul kann etwas Entropie entfernen. Siehe die Kommentare in drivers/char/random.c. Beachten Sie auch, dass entropy_avail bezieht sich auf den Eingabepool, nicht auf die Ausgabepools (im Grunde der nicht blockierende /dev/urandom und das blockierende /dev/random ).

Wenn Sie den Entropiepool überwachen müssen, verwenden Sie watch cat nicht , die bei jedem Aufruf von cat Entropie verbraucht . In der Vergangenheit wollte ich diesen Pool auch beobachten, da GPG beim Generieren von Schlüsseln sehr langsam war, daher habe ich ein C-Programm geschrieben, das ausschließlich dazu dient, den Entropie-Pool zu beobachten:https://git.lekensteyn.nl/c-files/tree /entropy-watcher.c.

Beachten Sie, dass es Hintergrundprozesse geben kann, die ebenfalls Entropie verbrauchen. Mit Tracepoints auf einem geeigneten Kernel können Sie die Prozesse sehen, die den Entropiepool ändern. Beispielverwendung, die alle Ablaufverfolgungspunkte aufzeichnet, die sich auf das zufällige Subsystem beziehen, einschließlich der Aufrufkette (-g ) auf allen CPUs (-a ) beginnt nach 1 Sekunde mit der Messung, um den eigenen Prozess zu ignorieren (-D 1000 ) und einschließlich Zeitstempel (-T ):

sudo perf record -e random:\* -g -a -D 1000 -T sleep 60

Lesen Sie es mit einem dieser Befehle (Ändern Sie den Besitzer von perf.data nach Bedarf):

perf report  # opens an interactive overview
perf script  # outputs events after each other with traces

Die perf script Die Ausgabe gibt einen interessanten Einblick und zeigt, wann etwa 8 Bytes (64 Bit) Entropie regelmäßig auf meiner Maschine verbraucht werden:

kworker/0:2   193 [000]  3292.235908:       random:extract_entropy: ffffffff8173e956 pool: nbytes 8 entropy_count 921 caller _xfer_secondary_pool
                  5eb857 extract_entropy (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  5eb984 _xfer_secondary_pool (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  5ebae6 push_to_pool (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  293a05 process_one_work (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  293ce8 worker_thread (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  299998 kthread (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  7c7482 ret_from_fork (/lib/modules/4.6.2-1-ARCH/build/vmlinux)

kworker/0:2   193 [000]  3292.235911:         random:debit_entropy: ffffffff8173e956: debit_bits 64
                  5eb3e8 account.part.12 (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  5eb770 extract_entropy (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  5eb984 _xfer_secondary_pool (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  5ebae6 push_to_pool (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  293a05 process_one_work (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  293ce8 worker_thread (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  299998 kthread (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  7c7482 ret_from_fork (/lib/modules/4.6.2-1-ARCH/build/vmlinux)

...

swapper     0 [002]  3292.507720:   random:credit_entropy_bits: ffffffff8173e956 pool: bits 2 entropy_count 859 entropy_total 2 caller add_interrupt_randomness
                  5eaab6 credit_entropy_bits (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  5ec644 add_interrupt_randomness (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  2d5729 handle_irq_event_percpu (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  2d58b9 handle_irq_event (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  2d8d1b handle_edge_irq (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  230e6a handle_irq (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  7c9abb do_IRQ (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  7c7bc2 ret_from_intr (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  6756c7 cpuidle_enter (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  2bd9fa call_cpuidle (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  2bde18 cpu_startup_entry (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
                  2510e5 start_secondary (/lib/modules/4.6.2-1-ARCH/build/vmlinux)

Anscheinend geschieht dies, um eine Verschwendung von Entropie zu verhindern, indem Entropie aus dem Eingabepool in die Ausgabepools übertragen wird:

/*
 * Credit (or debit) the entropy store with n bits of entropy.
 * Use credit_entropy_bits_safe() if the value comes from userspace
 * or otherwise should be checked for extreme values.
 */
static void credit_entropy_bits(struct entropy_store *r, int nbits)
{
    ...
        /* If the input pool is getting full, send some
         * entropy to the two output pools, flipping back and
         * forth between them, until the output pools are 75%
         * full.
         */

         ...
            schedule_work(&last->push_work);
}

/*
 * Used as a workqueue function so that when the input pool is getting
 * full, we can "spill over" some entropy to the output pools.  That
 * way the output pools can store some of the excess entropy instead
 * of letting it go to waste.
 */
static void push_to_pool(struct work_struct *work)
{
    ...
}

lsof ist nicht das beste Tool, um /dev/random zu überwachen wie man von einem Prozess gelesen wird, ist in sehr vorbei kurze Zeit. Ich kenne keine gute Methode, um herauszufinden, welcher Prozess einen Lesevorgang durchführt, aber ich verwende inotify Sie können if überwachen da ist ein Lesezeichen.

Hier gibt es grundsätzlich zwei Möglichkeiten:

1. Erhalten Sie eine Zusammenfassung nach N Sekunden mit:

   inotifywatch -v -t 60 /dev/random 
   

2. live ansehen Zugriffsereignisse:

   inotifywait -m --timefmt '%H:%M:%S' --format '%T: %e' /dev/random
   

Beides wird Ihnen keinen Prozess geben und letzteres wird Ihnen keine Lesegröße geben. Die erste gibt Ihnen eine Zusammenfassung wie in:

total  access  close_nowrite  open  filename
18     16      1              1     /dev/random

Wenn Sie das laufen lassen und einen dd if=/dev/random of=/tmp/foo bs=1 count=3 ausführen , du verstehst schon.

Jedenfalls. Dadurch erhalten Sie keine Ticks, wenn der Kernel aus dem Pool verbraucht.

Wenn es darum geht, den Status der Entropie mit

zu überprüfen

watch cat /proc/sys/kernel/random/entropy_avail

ist nicht die beste Idee, da jeder cat wird Entropie verbrauchen. (Ich sehe jetzt, dass eine andere Antwort aufgetaucht ist, die dies ebenfalls erwähnt.) Ich habe auch C-Code dafür und habe gestern versucht, ihn zu finden. Ich werde sehen, ob ich es finden kann, und die Antwort später aktualisieren.