https://sourceware.org/ml/libc-alpha/2018-05/msg00891.html
https://sourceware.org/bugzilla/show_bug.cgi?id=4417
https://www.openwall.com/lists/musl/2018/07/03/3
If glibc had added it then musl libc would have and all would be right with the world, at least from the perspective of userland. The kernel would still need to get its story straight.
I once had the (dis)pleasure of meeting him once at a former company when he came onsite and he came across as every bit the condescending asshole as he does on bigzilla. Didn't really get the chance to get to know him as a person, but as they say, first impressions... I get that he's in a tough spot maintaining glibc, but a bit of tack in correspondence would go a long way.
I get where either were coming from (BSD was open-sourcing an established codebase, Linux was a from-scratch effort), but it does seem like that foundational culture persisted.
Sounds like GLibc is more of the latter.
Theo de Raat doesn't suffer any fools. He calls bullshit as soon as he sees it (ok, Linis does too) and is fairly uncompromising when it comes to code quality and security regardless of whether it's kernel or userspace.
Seems to me, Linus is primarily focused on kernel space being secure and as long as kernel changes dont break userspace, hes cool.
I appreciate both views, but tend to like Theo's better.
Has musl committed to adding it if glibc does? If not, why would musl add it?
> ... glibc has adding [sic] the arc4random interfaces and it seems reasonable that we should too....
How does OpenBSD deal with this issue?
# Push the old seed into the kernel, create a future seed and create a seed
# file for the boot-loader.
random_seed() {
dd if=/var/db/host.random of=/dev/random bs=65536 count=1 status=none
chmod 600 /var/db/host.random
dd if=/dev/random of=/var/db/host.random bs=65536 count=1 status=none
dd if=/dev/random of=/etc/random.seed bs=512 count=1 status=none
chmod 600 /etc/random.seed
}
FreeBSD:
* https://svnweb.freebsd.org/base/head/libexec/save-entropy/
* https://www.freebsd.org/cgi/man.cgi?loader.conf(5) (see "entropy_cache_load")
OpenBSD's boot loader also injects entropy into the kernel.
This business of /var/ not being writable early enough is probably to do with the wonderful complexities of modern Linux, and is just not a problem that OpenBSD has.
They also do it at shutdown, before /var is R/O or unmounted.
One can also have multiple files, and have a regular cron job that replaces one of them occasionally while the system is running. This is what the FreeBSD script does.
* https://svnweb.freebsd.org/base/head/libexec/save-entropy/
* https://svnweb.freebsd.org/base/head/libexec/rc/rc.d/random
Other systems have solved this problem, so I'm not sure why all the high drama with Linux.
FreeBSD runs a regular cron job so that there are multiple files. If /var goes R-O, you still have a bunch of files from when it wasn't and they are not the same as on initial boot (assuming that (a) /var was mounted R-W at some point, and (b) cron managed to run as well).
Also, on shutdown there is an attempt to write 4096B to both /entropy and /boot/entropy:
* https://svnweb.freebsd.org/base/head/libexec/rc/rc.d/random?...
Further, all of these various seed files are not the only sources of entropy (timers, RDRAND, etc).
Not a good assumption if the initial r/w mount is the one that fails...
But for >99% of cases where the system comes up cleanly, and runs cleanly for a period of time, you'll have a bunch of seed files ready to go for the next boot. This configuration optimizes for the common case.
https://svnweb.freebsd.org/base/head/libexec/rc/rc.d/random?...
Similar idea to what OpenBSD does.
Incidentally, I really wish we could get the arc4random(3) family on GNU/Linux already. It's the only notable *NIX platform that still doesn't provide it; illumos has it, every BSD has it, macOS has it. Given the difficulties with entropy as noted above, however, the whole "non-failing cryptographically secure PRNG" model just won't work with Linux.