4 ms·

Actually, the preferred and recommended way to get randomness on modern kernels is to use the new getrandom(2) system call, with the flags argument set to zero.

by tytso 11y ago

Actually, the preferred and recommended way to get randomness on modern kernels is to use the new getrandom(2) system call, with the flags argument set to zero. http://man7.org/linux/man-pages/man2/getrandom.2.html http://man7.org/linux/man-pages/man2/getrandom.2.html With the flags set to zero, it works like the getentropy(2) system call in OpenBSD. In fact, code that uses getentropy(buf, buflen) can be trivially ported to Linux as getrandom(buf, buflen, 0).

plonh 11y ago
Why didn't we get /dev/getrandom?
- viraptor 11y ago
  One point of a direct syscall is that you don't have to open any files. That protects you from file descriptor exhaustion attacks.
  - cperciva 11y ago
    Another point is that it still works if you're inside a chroot / jail / container / with no devices visible.
    - rakoo 11y ago
      In a way, that's the point of chroot/jail/container: isolate the host filesystem from the guest, so the script that creates it should take /dev into account if it is needed
      - Dylan16807 11y ago
        The point is to isolate access to the host, and single secure random numbers have nothing to do with the host.
- kalleboo 11y ago
  Here's the original syscall request http://lists.openwall.net/linux-kernel/2014/07/17/235 http://lists.openwall.net/linux-kernel/2014/07/17/235 and discussion https://news.ycombinator.com/item?id=8049180 https://news.ycombinator.com/item?id=8049180
deleted 11y ago
[deleted]
hsivonen 11y ago
If the right way to use the Linux system call is to use it with flags set to such that it becomes equivalent to the OpenBSD system call, 1) Why does the Linux system call have flags at all? 2) Why does the Linux system call have a different name? I.e. why not clone the OpenBSD system call exactly with the same name and semantics and not give the userland any flags to shoot self in the foot with?
- masklinn 11y ago
  http://thread.gmane.org/gmane.linux.kernel/1750023 http://thread.gmane.org/gmane.linux.kernel/1750023 (you certainly don't have to agree with that, currently all the flags can do is draw from /dev/random instead of /dev/urandom, and do so without blocking, but that's the reasoning behind the interface change and thus the name change)
  - hsivonen 11y ago
    It's pretty sad that the embedded system problem is exposed to the userland, which isn't a reasonable place to deal with the problem. A better solution would be to require the bootloader to supply the kernel with a seed (as, I gather, OpenBSD deals with the problem) and not support hardware that doesn't have at least one of 1) hardware rng or 2) 256 bits of non-volatile storage for storing a seed across boots available to the bootloader.
technion 11y ago
Unfortunately at the moment, it's not a safe call that any particular system is actually running a modern enough kernel imo. getrandom() showed up in 3.17, and the latest CentOS distribution ships with 3.10. And then you've got older deployments. You could play with autoconf hell of detecting getrandom() and compiling for it if needed, but I couldn't imagine it to be worth the effort at the moment if you're going to be maintaining a branch of fallback code anyway.
beefhash 11y ago
This is all fine and dandy for seeding a CSPRNG, but we still don't actually have a CSPRNG in the C stdlib or glibc. getrandom(2) seems to target exclusively getting entropy for seeding, looking at the man page ("These bytes can be used to seed userspace random number generators or for cryptographic purposes."). And of course, the syscall is very recent, introduced in Linux 3.17, coming after the kernels in Debian stable (jessie), which features 3.16, and CentOS/RHEL7, which features 3.10. OpenBSD and NetBSD feature a ChaCha-based arc4random; FreeBSD and libbsd still seem stuck with RC4-based arc4random[1]. An equivalent for that is sorely missing on Linux. /dev/urandom requires messing with file descriptors, which you may run out of and may require error handling, plus all kinds of security precautions to make sure you're actually looking at the right /dev/urandom[2]. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=182610 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=182610 and https://bugs.freedesktop.org/show_bug.cgi?id=85827 https://bugs.freedesktop.org/show_bug.cgi?id=85827 [2] http://insanecoding.blogspot.ch/2014/05/a-good-idea-with-bad-usage-devurandom.html http://insanecoding.blogspot.ch/2014/05/a-good-idea-with-bad...
- ReidZB 11y ago
  getrandom(2) uses a CSPRNG under the hood and can be treated as a pre-seeded one. It's unfortunate that it's so recent, though.
- justincormack 11y ago
  There is an open request to add a posix_random (basically arc4random) to posix http://austingroupbugs.net/view.php?id=859 http://austingroupbugs.net/view.php?id=859

by tytso 11y ago

plonh 11y ago

Why didn't we get /dev/getrandom?

viraptor 11y ago
One point of a direct syscall is that you don't have to open any files. That protects you from file descriptor exhaustion attacks.
- cperciva 11y ago
  Another point is that it still works if you're inside a chroot / jail / container / with no devices visible.
  - rakoo 11y ago
    In a way, that's the point of chroot/jail/container: isolate the host filesystem from the guest, so the script that creates it should take /dev into account if it is needed
    - Dylan16807 11y ago
      The point is to isolate access to the host, and single secure random numbers have nothing to do with the host.
kalleboo 11y ago
Here's the original syscall request http://lists.openwall.net/linux-kernel/2014/07/17/235 http://lists.openwall.net/linux-kernel/2014/07/17/235 and discussion https://news.ycombinator.com/item?id=8049180 https://news.ycombinator.com/item?id=8049180

deleted 11y ago

[deleted]

hsivonen 11y ago

If the right way to use the Linux system call is to use it with flags set to such that it becomes equivalent to the OpenBSD system call, 1) Why does the Linux system call have flags at all? 2) Why does the Linux system call have a different name? I.e. why not clone the OpenBSD system call exactly with the same name and semantics and not give the userland any flags to shoot self in the foot with?

masklinn 11y ago
http://thread.gmane.org/gmane.linux.kernel/1750023 http://thread.gmane.org/gmane.linux.kernel/1750023 (you certainly don't have to agree with that, currently all the flags can do is draw from /dev/random instead of /dev/urandom, and do so without blocking, but that's the reasoning behind the interface change and thus the name change)
- hsivonen 11y ago
  It's pretty sad that the embedded system problem is exposed to the userland, which isn't a reasonable place to deal with the problem. A better solution would be to require the bootloader to supply the kernel with a seed (as, I gather, OpenBSD deals with the problem) and not support hardware that doesn't have at least one of 1) hardware rng or 2) 256 bits of non-volatile storage for storing a seed across boots available to the bootloader.

technion 11y ago

Unfortunately at the moment, it's not a safe call that any particular system is actually running a modern enough kernel imo. getrandom() showed up in 3.17, and the latest CentOS distribution ships with 3.10. And then you've got older deployments. You could play with autoconf hell of detecting getrandom() and compiling for it if needed, but I couldn't imagine it to be worth the effort at the moment if you're going to be maintaining a branch of fallback code anyway.

beefhash 11y ago

This is all fine and dandy for seeding a CSPRNG, but we still don't actually have a CSPRNG in the C stdlib or glibc. getrandom(2) seems to target exclusively getting entropy for seeding, looking at the man page ("These bytes can be used to seed userspace random number generators or for cryptographic purposes."). And of course, the syscall is very recent, introduced in Linux 3.17, coming after the kernels in Debian stable (jessie), which features 3.16, and CentOS/RHEL7, which features 3.10. OpenBSD and NetBSD feature a ChaCha-based arc4random; FreeBSD and libbsd still seem stuck with RC4-based arc4random[1]. An equivalent for that is sorely missing on Linux. /dev/urandom requires messing with file descriptors, which you may run out of and may require error handling, plus all kinds of security precautions to make sure you're actually looking at the right /dev/urandom[2]. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=182610 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=182610 and https://bugs.freedesktop.org/show_bug.cgi?id=85827 https://bugs.freedesktop.org/show_bug.cgi?id=85827 [2] http://insanecoding.blogspot.ch/2014/05/a-good-idea-with-bad-usage-devurandom.html http://insanecoding.blogspot.ch/2014/05/a-good-idea-with-bad...

ReidZB 11y ago
getrandom(2) uses a CSPRNG under the hood and can be treated as a pre-seeded one. It's unfortunate that it's so recent, though.
justincormack 11y ago
There is an open request to add a posix_random (basically arc4random) to posix http://austingroupbugs.net/view.php?id=859 http://austingroupbugs.net/view.php?id=859