entropy_avail hat dauerhaft 256!? ✔️

[GwenDragon]

watch -n1 cat /proc/sys/kernel/random/entropy_avail zeigt mir immer 256.
Früher war der Wert um 3600-4000.
Kernel: 5.10.0-15-amd64 #1 SMP Debian 5.10.120-1 (2022-06-09)

root@s12  /proc/sys/kernel/random/ # cat  entropy_avail
256
root@s12 /proc/sys/kernel/random # cat urandom_min_reseed_secs
60
root@s12 /proc/sys/kernel/random # cat poolsize
256
root@s12 /proc/sys/kernel/random # cat write_wakeup_threshold
256

/edit: Sieht mir nach Debian Bullseye-Bug aus., weil die Ubuntu 22-Server das nicht haben.
Wohl dadurch: https://www.debian.org/security/2022/dsa-5161

Ja, da hat tatsächlich 2022-06-11 bei dem Server ein Update des Kernel von linux-image-5.10.0-13-amd64 → linux-image-5.10.0-15-amd64 stattgefunden.
So, nun muss ich mir die verantwortliche Person suchen, die das veranlasste.

 

[GwenDragon]

Mal alle drei Images gebooted und interessant ist die Konfig-Änderung durch die Debian-Maintainer nach dem Security-Release im Juni:

Linux s12 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 (2021-12-08) x86_64

kernel.random.entropy_avail = 613
kernel.random.poolsize = 4096
kernel.random.urandom_min_reseed_secs = 60
kernel.random.write_wakeup_threshold = 896

---------------

Linux s12 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) x86_64 GNU/Linux

kernel.random.entropy_avail = 372
kernel.random.poolsize = 4096
kernel.random.urandom_min_reseed_secs = 60
kernel.random.write_wakeup_threshold = 896

---------------

Linux s12 5.10.0-15-amd64 #1 SMP Debian 5.10.120-1 (2022-06-09) x86_64 GNU/Linux

kernel.random.entropy_avail = 256
kernel.random.poolsize = 256
kernel.random.urandom_min_reseed_secs = 60
kernel.random.write_wakeup_threshold = 256

 

[GwenDragon]

Ah, endlich ein Changelog in den Sources gefunden: https://sources.debian.org/src/linux/5.10.120-1/debian/changelog/
Die haben überall an random gepatcht.

 

[Joe User]

Aus dem Changelog geht aber nicht hervor, ob die jeweiligen Patches von Upstream oder Debian stammen.

Es wäre also besser, die von Debian stammenden 3rd-Party Patches durchzusehen...

Vielleicht hat ja auch Ubuntu ein paar Upstream-Patches nicht eingepflegt oder reverted...

 

[Col_Kernel]

Aus dem Changelog geht aber nicht hervor, ob die jeweiligen Patches von Upstream oder Debian stammen.

Doch. Die ganzen Änderungen an "random" auf die sich GwenDragon (vermutlich) bezieht, stehen alle unter "New upstream stable update". Die Debian-spezifischen Änderungen sind die paar wenigen in Zeilen 537-543 und 1366-1373.

 

[GwenDragon]

Leider kann ich nicht interpretieren, warum diese Änderungen an der Debian-Kernel-Konfig passierten, ich bin keine Kernelprogrammieerin.

Wie wirkst sich denn eine geringe Poolsize und Write_Wakeup_Threshold auf die Sicherheit von Services und Programme aus?
Sollte das Einfluss auf z.B. GnuPG, OpenSSL etc. haben?

Oder sollte ich wieder mit sysctl die alten Werte für kernel.random... einsetzen?

 

[Joe User]

Doch. Die ganzen Änderungen an "random" auf die sich GwenDragon (vermutlich) bezieht, stehen alle unter "New upstream stable update". Die Debian-spezifischen Änderungen sind die paar wenigen in Zeilen 537-543 und 1366-1373.

Oh, das ist mir bei der Länge des Changelogs glatt nicht aufgefallen Asche auf mein Haupt...


Gut, da Debian laut Changelog zumindest diesbezüglich nicht am Kernel gepfuscht hat, muss es entweder Upstream passiert sein, oder Debian manipuliert die Sysctl ausserhalb des Kernels...

 

[GwenDragon]

Gut, da Debian laut Changelog zumindest diesbezüglich nicht am Kernel gepfuscht hat, muss es entweder Upstream passiert sein, oder Debian manipuliert die Sysctl ausserhalb des Kernels...

Gerätselt hab ich auch genug, die C-Sources von random.c durchsucht nach Kommentaren - nada.

OK, ich lass den Server erst mal so wie er mit kernel.random nun ist. Man wird mir schon Bescheid sagen, wenn irgendwas nicht läuft, ich manage den Server ja eh nicht.

Ich hab gedacht, irgendjemand von euch wüsste was zu den Änderungen, aber Debian wird wohl wenig genutzt.

 

[Col_Kernel]

Hab gerade meinen Debian-Server testweise neugebootet, und ich sehe diese Änderung auch seit 5.10.120-1. Ich denke aber nicht, dass es eine Debian-spezifische Änderung ist. Andere Distribution werden die wohl auch abbekommen (bzw. haben das schon).

entropy_avail ist auch read-only (im Gegensatz zu urandom_min_reseed_secs und write_wakeup_threshold). Ich denke nicht, dass das ein sysctl-Wert ist, den man konfigurieren kann. Wohl eher ein Statuswert, den man ausschließlich lesen kann.

Angesichts der ganzen Zeilen zu "random" im Changelog sieht mir das nach einer größeren Änderung aus, so dass sich der Kernel hier jetzt einfach anders verhält, und insbesondere dieser Statuswert. Für genaueres müsste man wohl die git Commit Messages von Linux anschauen und/oder auf deren Mailingslisten suchen.

 

[Deleted member 3190]

Moin

Ich hab dazu hier: kernel 5.10.119 caused the values of /proc/sys/kernel/random/entropy_avail and poolsize to be 256 was gefunden, das die wesentlichen Aspekte erklärt.

 

[GwenDragon]

Das ist wohl die Änderung des Aufrufs eines anderen Generators

[PATCH 5.15 038/145] random: use computational hash for entropy extraction - Greg Kroah-Hartman

lore.kernel.org

This being achieved by replacing the 4096 LFSR by a direct call to the BLAKE2s.

Siehe StackExchange

Ok, dann ist das auch so klarer geworden, slebst wenn ich keien Kernel-Programmiererin bin.

@Thorashh Danke für deinen Hinweis.

 

[GwenDragon]

Heut bekam ich ein Mail aus der Liste debian-security-announce :

[SECURITY] [DSA 5173-1] linux security update

(…)

The random driver has been backported from Linux 5.19, fixing numerous
performance and correctness issues. Some changes will be visible:

- - The entropy pool size is now 256 bits instead of 4096. You may need
to adjust the configuration of system monitoring or user-space
entropy gathering services to allow for this.

- - On systems without a hardware RNG, the kernel may log more uses of
/dev/urandom before it is fully initialised. These uses were
previously under-counted and this is not a regression.

Also doch wie vermutet: backported & die Einstellung kann wenn nötig angepasst werden auf einen höheren Wert.

Na, dann gebe ich das mal weiter.