9 ms·

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 sho

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.

brynet 7y ago
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.
- beefhash 7y ago
  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.
  - tedunangst 7y ago
    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.
wahern 7y ago
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.
- saagarjha 7y ago
  > 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?
  - wahern 7y ago
    See Rich Felker's original message to which Florian Weimer (glibc patch author) replied: https://www.openwall.com/lists/musl/2018/07/02/5 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....
- justin66 7y ago
  The bugzilla is classic Ulrich Drepper. Ugh.
  - hermitdev 7y ago
    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.
    - AceJohnny2 7y ago
      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.
      - hermitdev 7y ago
bonzini 7y ago
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?
- tedunangst 7y ago
  Read the seed on boot, replace it when possible.
- magicalhippo 7y ago
  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.
  - bonzini 7y ago
    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.
- throw0101a 7y ago
  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 https://cvsweb.openbsd.org/src/etc/rc?rev=1.537 FreeBSD: * https://svnweb.freebsd.org/base/head/libexec/save-entropy/ https://svnweb.freebsd.org/base/head/libexec/save-entropy/ * https://www.freebsd.org/cgi/man.cgi?loader.conf(5) https://www.freebsd.org/cgi/man.cgi?loader.conf(5) (see "entropy_cache_load") OpenBSD's boot loader also injects entropy into the kernel.
  - 7y ago
TorKlingberg 7y ago
Read-only file systems are common in embedded systems, where Linux is often used.

brynet 7y ago

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.

beefhash 7y ago
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.
- tedunangst 7y ago
  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.

wahern 7y ago

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.

saagarjha 7y ago
> 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?
- wahern 7y ago
  See Rich Felker's original message to which Florian Weimer (glibc patch author) replied: https://www.openwall.com/lists/musl/2018/07/02/5 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....
justin66 7y ago
The bugzilla is classic Ulrich Drepper. Ugh.
- hermitdev 7y ago
  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.
  - AceJohnny2 7y ago
    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.
    - hermitdev 7y ago

bonzini 7y ago

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?

tedunangst 7y ago
Read the seed on boot, replace it when possible.
magicalhippo 7y ago
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.
- bonzini 7y ago
  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.
throw0101a 7y ago
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 https://cvsweb.openbsd.org/src/etc/rc?rev=1.537 FreeBSD: * https://svnweb.freebsd.org/base/head/libexec/save-entropy/ https://svnweb.freebsd.org/base/head/libexec/save-entropy/ * https://www.freebsd.org/cgi/man.cgi?loader.conf(5) https://www.freebsd.org/cgi/man.cgi?loader.conf(5) (see "entropy_cache_load") OpenBSD's boot loader also injects entropy into the kernel.
- 7y ago

TorKlingberg 7y ago

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