Hacker News Reader

Comment by beefhash | Hacker News Reader

There may be some systems where storing entropy in a file across reboots isn't an option, e.g. diskless situations or non-writable filesystems. Though those should be a rare case. Of course, this would actually require cooperation from userspace, and given Linux is just a kernel and userland kind of free to do what they want, it's not as easy as it sounds.

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.

View on HN

arc4random almost made it into glibc 2.28:

  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

That patch was held over for 2.29 but then disappeared.

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.

> If glibc had added it then musl libc would have

Has musl committed to adding it if glibc does? If not, why would musl add it?

See Rich Felker's original message to which Florian Weimer (glibc patch author) replied: https://www.openwall.com/lists/musl/2018/07/02/5

> ... glibc has adding [sic] the arc4random interfaces and it seems reasonable that we should too....

The bugzilla is classic Ulrich Drepper. Ugh.

Some much truth to this. Those that think Linus or RMS are abrassive have obviously never met Drepper.

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 figured that the reason the Linux kernel gained popularity originally was because Torvalds was so open about accepting contributions. This compared to BSD which had "standards".

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.

I see where you're going, but I don't agree we're at the same endpoint. One should generally be accepting of changes, but they should be worthwhile.

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.

His whitepaper on memory is a fantastic read, though (if with a somewhat clickbaity title).

https://www.akkadia.org/drepper/cpumemory.pdf

I'm not saying he hasn't made contributions to the community. He surely has made more than I have, and very valuable ones at that. I'm just saying interacting with him is not pleasant.

Drepper has been gone from glibc for many years now.

I haven't seen anything criminal in his reply. Can you clarify what's so offending about this discussion, please?

If I submit a patch and get a response like Ulrich's, that's a great way to ensure I'm never going to bother contributing to that project again.

The API was being added to Unix libcs left and right, giving it wide adoption and validation, making it an informal or de facto standard. He was dismissing it as some "dumping ground" code and sarcastically saying "ok, nice work, that would go great in your own project ..."

systemd does store the entropy in a file, but Lennart says this in the comments of the article: "we can only credit a random seed read from disk when we can also update it on disk, so that it is never reused. This means /var needs to be writable, which is really later during boot, long after we already needed entropy".

How does OpenBSD deal with this issue?

Read the seed on boot, replace it when possible.

It's also said that adding entropy to the pool can never make it worse, no? So why not just add it anyway. If you get to replace it, great! If not, well you tried.

Yes, but you should not credit the entropy you added if you're not sure it's never been used before. And you need to credit it to avoid hangs.

From rc(8):

  # 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
  }

* https://cvsweb.openbsd.org/src/etc/rc?rev=1.537

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.

Which is to say, /var/ is writable when they do it.

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.

This is a fancy way of saying it's systemd's fault. (/s)

What if a filesystem error forces /var (or whichever mount point hosts the entropy seed) to remain read-only and seed is never replaced? Seems like unlike systemd the BSDs are fine with crediting entropy even if it has been used already in a previous boot. That's wrong though.

> Seems like unlike systemd the BSDs are fine with crediting entropy even if it has been used already in a previous boot.

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).

> (assuming that (a) /var was mounted R-W at some point

Not a good assumption if the initial r/w mount is the one that fails...

If the initial /var (or /) is broken, then one has bigger problems and probably has to go in manually to fix things.

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.

> Which is to say, /var/ is writable when they do it.

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 saves entropy in two places; the one you've linked is only loaded after userspace starts (via rc.d/random). The boot-time entropy mentioned in loader.conf is also created and saved in rc.d/random:

https://svnweb.freebsd.org/base/head/libexec/rc/rc.d/random?...

Similar idea to what OpenBSD does.

The boot-loader injects randomness into the kernel before starting the kernel (using the saved random seed file), so you can have randomness from the very first bit of initialization.

If you cannot guarantee that the entropy has never been used before, that's bad.

It is guaranteed to not be worse than no injected entropy at all, which is the default and only possible alternative state before the kernel starts, it always gets mixed with what can be gathered.

OpenBSD doesn't have systemd.

Sure it would, except nobody is brave enough to do it. They're too busy attacking some detail, this week it's diskless situations, next week it's "untrusted" random hardware/rdrand, and ignore a system that mixes components together.

I suppose that's the curse of the success of Linux. Now that it's everywhere, it also has to answer to all kinds of usage scenarios.

The problem is not intractable if you are willing to solve pieces of it. Then you solve another piece. Then somebody realizes they're the odd man out, and they solve their piece.

Read-only file systems are common in embedded systems, where Linux is often used.

Reply on news.ycombinator.com