Fragen? Antworten! Siehe auch: Alternativlos
getrandom ist ein neuer Syscall, der einem Zufall liefert, als würde man aus /dev/urandom lesen. getentropy ist ein Wrapper um getrandom, der, wenn der Syscall nicht verfügbar ist, halt /dev/urandom öffnet und daraus liest.
In neuen Code solltet ihr getentropy verwenden. Das API kommt von OpenBSD.
Wieso getentropy nehmen und nicht aus /dev/urandom lesen? Weil getentropy, wenn der Syscall verfügbar ist, nicht /dev/urandom öffnen muss, d.h. das Programm funktioniert auch in einem chroot-Jail, in dem der Admin /dev/urandom anzulegen vergessen hat.
Das OpenBSD-API sagt, dass getentropy höchstens 256 Bytes auf einmal liefern kann. Den getrandom-Syscall gibt es seit Linux 3.17.
Ich hatte Support für getrandom und getentropy in der dietlibc, seit ich von dem API gehört hatte, aber ich hatte die Prototypen nach unistd.h getan. glibc tut es nach sys/random.h. Ich habe dietlibc also jetzt geändert, auch sys/random.h zu benutzen.
Update: Oh und noch eine gute Nachricht: Wenn ihr openssh mit der neuen glibc übersetzt, sollte das direkt tun, denn ich habe vor einer Weile bei denen einen Bug gefiled, dass der getrandom-Syscall in ihrer Sandbox freigeschaltet werden muss. Haben sie sofort getan. Müsste also alles out of the box funktionieren.
Update: Es gibt noch andere Gründe für getentropy. Aus der Manpage zu getrandom:
If the urandom source has not yet been initialized, then getrandom()Das umgeht elegant ein wichtiges Sicherheitsproblem, wenn Geräte zum Bootzeitpunkt noch nicht genug Entropie gesammelt haben.
will block, unless GRND_NONBLOCK is specified in flags.
Update: Den Fallback-Code scheint es in glibc nicht zu geben. Ich nahm an, dass die den haben werden, weil glibc sonst für jeden Scheiß einen Fallback-Code hat, und ich natürlich in dietlibc auch einen Fallback implementiert habe.