fff-random: syscall statt manuell /dev/urandom lesen #72

New Issue

jkimmel · 2021-01-09T08:38:33+01:00

jkimmel commented

2021-01-09 08:38:33 +01:00

Diesen ganzen Block hier könnte man durch einen syscall nach getrandom ersetzen.

Wenn das nicht portabel genug ist, kann natürlich auch die Variante mit rand() bauen. Dann hätte man nur C Standardbibliothek benutzt. Hätte auch etwas.

Ist keine wichtige Sache, aber vielleicht mal eine nette Fingerübung für zwischendurch.

Diesen [ganzen Block hier](https://git.freifunk-franken.de/freifunk-franken/firmware/src/commit/5469399112dbb312323e0e508482fb3db1a24829/src/packages/fff/fff-random/src/random.c#L36-L48) könnte man durch einen syscall nach `getrandom` ersetzen. Wenn das nicht portabel genug ist, kann natürlich auch die Variante mit `rand()` bauen. Dann hätte man nur C Standardbibliothek benutzt. Hätte auch etwas. Ist keine wichtige Sache, aber vielleicht mal eine nette Fingerübung für zwischendurch.

jkimmel added the

packages/fff

label 2021-01-09 08:38:33 +01:00

adschm commented

2021-01-09 12:48:17 +01:00

Wichtig ist dabei halt, dass wir eine Quelle behalten, die nicht initialisiert werden muss. Keine Ahnung, ob das für die vorgeschlagenen Änderungen erfüllt ist.

jkimmel commented

2021-01-09 12:56:16 +01:00

Jo, auch da ist getrandom vermutlich besser. Laut man 7 random blockiert getrandom bis zum erstem mal der entropy pool auch wirklich initialisiert ist, waehrend /dev/urandom niemals blockiert. Danach aber nie wieder. Also man bekommt schon mal keinen beschissenen Zufall und wenn es einmal geklappt hat, kann man von anderen Prozessen auch nicht mehr blockiert werden, die den entropy pool leer saugen.

getrandom hat auch noch Parameter, um es komplett non-blocking zu machen. Da bekommt man immerhin mal einen Fehler, statt schlechten Zufall.

Jo, auch da ist `getrandom` vermutlich besser. Laut `man 7 random` blockiert `getrandom` bis zum erstem mal der entropy pool auch wirklich initialisiert ist, waehrend `/dev/urandom` niemals blockiert. Danach aber nie wieder. Also man bekommt schon mal keinen beschissenen Zufall und wenn es einmal geklappt hat, kann man von anderen Prozessen auch nicht mehr blockiert werden, die den entropy pool leer saugen. `getrandom` hat auch noch Parameter, um es komplett non-blocking zu machen. Da bekommt man immerhin mal einen Fehler, statt schlechten Zufall.

adschm commented

2021-01-12 15:41:55 +01:00

Jo, auch da ist getrandom vermutlich besser. Laut man 7 random blockiert getrandom bis zum erstem mal der entropy pool auch wirklich initialisiert ist, waehrend /dev/urandom niemals blockiert.

Ich habe das hier mit einem anderen Problem verwechselt. Für fastd haben wir damals explizit urandom genommen, damit wir genau auf das unblocking nicht warten müssen:
https://git.freifunk-franken.de/freifunk-franken/firmware/src/branch/master/feed_patches/openwrt/0020-fastd_generate_key_from_urandom.patch

Das war deshalb sinnvoll, weil für unser Setup der fastd-key ohnehin nur ein Platzhalter ist.

Inwieweit das für fff-random relevant ist, weiß ich nicht. Je nach Nutzer von fff-random muss dir halt bewusst sein, dass das Blockieren dann ggf. den Bootvorgang um 2-5 Minuten verlängert, bis das Gerät einsatzbereit und zugänglich ist.

> Jo, auch da ist getrandom vermutlich besser. Laut man 7 random blockiert getrandom bis zum erstem mal der entropy pool auch wirklich initialisiert ist, waehrend /dev/urandom niemals blockiert. Ich habe das hier mit einem anderen Problem verwechselt. Für fastd haben wir damals explizit urandom genommen, damit wir genau auf das unblocking nicht warten müssen: https://git.freifunk-franken.de/freifunk-franken/firmware/src/branch/master/feed_patches/openwrt/0020-fastd_generate_key_from_urandom.patch Das war deshalb sinnvoll, weil für unser Setup der fastd-key ohnehin nur ein Platzhalter ist. Inwieweit das für fff-random relevant ist, weiß ich nicht. Je nach Nutzer von fff-random muss dir halt bewusst sein, dass das Blockieren dann ggf. den Bootvorgang um 2-5 Minuten verlängert, bis das Gerät einsatzbereit und zugänglich ist.

Sign in to join this conversation.