6 ms·

It doesn't on OpenBSD. arc4random(3) simply can not fail, and getentropy(2) does not block. Linux screwed up getrandom. High quality random numbers are availabl

It doesn't on OpenBSD. arc4random(3) simply can not fail, and getentropy(2) does not block. Linux screwed up getrandom. High quality random numbers are available very early in the OpenBSD kernel, and there is no early boot problem for userland. Linux has an opportunity to learn from OpenBSD. https://www.openbsd.org/papers/hackfest2014-arc4random/index.html https://www.openbsd.org/papers/hackfest2014-arc4random/index...

throw0101a 7y ago
> High quality random numbers are available very early in the OpenBSD kernel, and there is no early boot problem for userland. OpenBSD also controls its own boot loader, which also feeds in entropy that the kernel then leverages. Perhaps GRUB(2) should do something similar?
- cat199 7y ago
  you mean you haven't heard of /etc/grub.conf.d/entropy.d/randomseed.d/grub-entropy-randomseed.conf and it's good buddy systemd-enable-grub-conf-d-entropy-d-randomseed-d.target ?
deathanatos 7y ago
Seems like they store entropy in an on-disk file[1], and re-read that file on startup. This feature is available in Linux as well (see urandom(4) for an example of how to do it manually, though I think most distros bundle this in some manner); although apparently, according to the OP, it doesn't fully work? Seems like the man page sort of notes the problem in the article: > Writing to /dev/random or /dev/urandom will update the entropy pool with the data written, but this will not result in a higher entropy count. But, why not, man page, why not? I feel like if I, as root, write to /dev/random, I am saying that this is acceptable input for seeding the generator, and that it is on me to not, say, seed it with the exact same stuff every boot, or seed it with straight nuls, no? How does OpenBSD guarantee that this file exists, though? Perhaps making it a system default is wise, but what about brand new VMs/installs? Does the install just take the time to do the first generation of that file? The OpenBSD folks also appear to trust RDRANG, which would help not blocking. But I disagree with that trust decision. [1]: start reading here: https://www.openbsd.org/papers/hackfest2014-arc4random/mgp00019.html https://www.openbsd.org/papers/hackfest2014-arc4random/mgp00...
- notaplumber 7y ago
  > The OpenBSD folks also appear to trust RDRANG, which would help not blocking. But I disagree with that trust decision. It feeds the entropy pool, mixed in with many sources. OpenBSD also feeds in data from the AMD CCP as well. The point is it doesn't matter. https://man.openbsd.org/ccp https://man.openbsd.org/ccp And anyone running "echo badapples > /dev/random" in a loop, it still doesn't matter. https://man.openbsd.org/random.4 https://man.openbsd.org/random.4 https://man.openbsd.org/arc4random.9 https://man.openbsd.org/arc4random.9 > How does OpenBSD guarantee that this file exists, though? If you keep reading, OpenBSD's random subsystem always mixes old with new data from many sources. If the random.seed file is not available (for example, boot media), it is not fatal. There is a warning displayed. But the system rc(8) scripts handle creating the seed file at both boot and shutdown. https://www.openbsd.org/papers/hackfest2014-arc4random/mgp00019.html https://www.openbsd.org/papers/hackfest2014-arc4random/mgp00...
  - deathanatos 7y ago
    > If you keep reading, OpenBSD's random subsystem always mixes old with new data from many sources. Sure. But say we don't trust RDRAND. It's the first boot, so you haven't got a seed file yet. Assuming you haven't got a HW generator at hand, what other source are there that don't take significant time to collect from? (I.e., I know you can get it from network timings, keyboard/mouse if they exist, etc., but that takes time, and would cause a call not wanting to return prior to there being sufficient data to block. If you're only mixing in unready or untrusted sources, you might get lucky and make it hard for an attacker, or worse, if your other sources are blocking b/c they're collecting data… you might not, but regardless it hardly seems principled?) It'd be willing to write off the first boot, except that I feel like a lot of things do potentially get initialized then; e.g., in a VM in the cloud, I think that's when host keys are initialized, for example, and certainly whatever application that VM might be hosting could have further requirements. Not blocking and issuing a warning would be to supply data prior to having sufficiently initialized a generator, no?
    - ori_b 7y ago
      > Sure. But say we don't trust RDRAND. It's the first boot, so you haven't got a seed file yet. Why not? The install media should be collecting entropy as it does the install, xoring it with a pool of random data built into it, and writing that to disk as part of the install. Take a look at https://github.com/openbsd/src/blob/master/distrib/miniroot/install.sub https://github.com/openbsd/src/blob/master/distrib/miniroot/..., specifically, feed_random and store_random
kevin_b_er 7y ago
SystemD, not linux, had an opportunity to learn from OpenBSD and actively refused.
- cat199 7y ago
  systemd didn't even learn from pseudo-systemv in this case - from tfa: "Basically as of now the entropy file saved as /var/lib/systemd/random-seed will not - drumroll - add entropy to the random pool when played back during boot. Actually it will. It will just not be accounted for. So Linux doesn't know. And continues blocking getrandom(). This is obviously different from SysVinit times2 when /var/lib/urandom/random-seed (that you still have lying around on updated systems) made sure the system carried enough entropy over reboot to continue working right after enough of the system was booted."
jmontano 7y ago
Linux handles random in weird ways. Once I migrated from Manjaro to Arch just to learn a bit more about Linux in general. Boot was extremely slow on Arch, but the same setup was ok on Manjaro. Thing was you need the Haveged daemon to generate entropy, something that should come within the kernel itself.
tjalfi 7y ago
arc4random was also submitted to POSIX[0] but they insisted on wrecking the design. [0] http://austingroupbugs.net/view.php?id=859 http://austingroupbugs.net/view.php?id=859

throw0101a 7y ago

> High quality random numbers are available very early in the OpenBSD kernel, and there is no early boot problem for userland. OpenBSD also controls its own boot loader, which also feeds in entropy that the kernel then leverages. Perhaps GRUB(2) should do something similar?

cat199 7y ago
you mean you haven't heard of /etc/grub.conf.d/entropy.d/randomseed.d/grub-entropy-randomseed.conf and it's good buddy systemd-enable-grub-conf-d-entropy-d-randomseed-d.target ?

deathanatos 7y ago

Seems like they store entropy in an on-disk file[1], and re-read that file on startup. This feature is available in Linux as well (see urandom(4) for an example of how to do it manually, though I think most distros bundle this in some manner); although apparently, according to the OP, it doesn't fully work? Seems like the man page sort of notes the problem in the article: > Writing to /dev/random or /dev/urandom will update the entropy pool with the data written, but this will not result in a higher entropy count. But, why not, man page, why not? I feel like if I, as root, write to /dev/random, I am saying that this is acceptable input for seeding the generator, and that it is on me to not, say, seed it with the exact same stuff every boot, or seed it with straight nuls, no? How does OpenBSD guarantee that this file exists, though? Perhaps making it a system default is wise, but what about brand new VMs/installs? Does the install just take the time to do the first generation of that file? The OpenBSD folks also appear to trust RDRANG, which would help not blocking. But I disagree with that trust decision. [1]: start reading here: https://www.openbsd.org/papers/hackfest2014-arc4random/mgp00019.html https://www.openbsd.org/papers/hackfest2014-arc4random/mgp00...

notaplumber 7y ago
> The OpenBSD folks also appear to trust RDRANG, which would help not blocking. But I disagree with that trust decision. It feeds the entropy pool, mixed in with many sources. OpenBSD also feeds in data from the AMD CCP as well. The point is it doesn't matter. https://man.openbsd.org/ccp https://man.openbsd.org/ccp And anyone running "echo badapples > /dev/random" in a loop, it still doesn't matter. https://man.openbsd.org/random.4 https://man.openbsd.org/random.4 https://man.openbsd.org/arc4random.9 https://man.openbsd.org/arc4random.9 > How does OpenBSD guarantee that this file exists, though? If you keep reading, OpenBSD's random subsystem always mixes old with new data from many sources. If the random.seed file is not available (for example, boot media), it is not fatal. There is a warning displayed. But the system rc(8) scripts handle creating the seed file at both boot and shutdown. https://www.openbsd.org/papers/hackfest2014-arc4random/mgp00019.html https://www.openbsd.org/papers/hackfest2014-arc4random/mgp00...
- deathanatos 7y ago
  > If you keep reading, OpenBSD's random subsystem always mixes old with new data from many sources. Sure. But say we don't trust RDRAND. It's the first boot, so you haven't got a seed file yet. Assuming you haven't got a HW generator at hand, what other source are there that don't take significant time to collect from? (I.e., I know you can get it from network timings, keyboard/mouse if they exist, etc., but that takes time, and would cause a call not wanting to return prior to there being sufficient data to block. If you're only mixing in unready or untrusted sources, you might get lucky and make it hard for an attacker, or worse, if your other sources are blocking b/c they're collecting data… you might not, but regardless it hardly seems principled?) It'd be willing to write off the first boot, except that I feel like a lot of things do potentially get initialized then; e.g., in a VM in the cloud, I think that's when host keys are initialized, for example, and certainly whatever application that VM might be hosting could have further requirements. Not blocking and issuing a warning would be to supply data prior to having sufficiently initialized a generator, no?
  - ori_b 7y ago
    > Sure. But say we don't trust RDRAND. It's the first boot, so you haven't got a seed file yet. Why not? The install media should be collecting entropy as it does the install, xoring it with a pool of random data built into it, and writing that to disk as part of the install. Take a look at https://github.com/openbsd/src/blob/master/distrib/miniroot/install.sub https://github.com/openbsd/src/blob/master/distrib/miniroot/..., specifically, feed_random and store_random

kevin_b_er 7y ago

SystemD, not linux, had an opportunity to learn from OpenBSD and actively refused.

cat199 7y ago
systemd didn't even learn from pseudo-systemv in this case - from tfa: "Basically as of now the entropy file saved as /var/lib/systemd/random-seed will not - drumroll - add entropy to the random pool when played back during boot. Actually it will. It will just not be accounted for. So Linux doesn't know. And continues blocking getrandom(). This is obviously different from SysVinit times2 when /var/lib/urandom/random-seed (that you still have lying around on updated systems) made sure the system carried enough entropy over reboot to continue working right after enough of the system was booted."

jmontano 7y ago

Linux handles random in weird ways. Once I migrated from Manjaro to Arch just to learn a bit more about Linux in general. Boot was extremely slow on Arch, but the same setup was ok on Manjaro. Thing was you need the Haveged daemon to generate entropy, something that should come within the kernel itself.

tjalfi 7y ago

arc4random was also submitted to POSIX[0] but they insisted on wrecking the design. [0] http://austingroupbugs.net/view.php?id=859 http://austingroupbugs.net/view.php?id=859