We have a request to add getrandom support to glibc (bug 1329996). This makes only sense if there is kernel support because emulation in glibc will be iffy.
getrandom was introduced upstream in 3.17:
Author: Theodore Ts'o <email@example.com>
Date: Thu Jul 17 04:13:05 2014 -0400
random: introduce getrandom(2) system call
There seem to have been a couple of fixes/internal API changes since then.
Just noting that this is likely to be important for userspace/kernel container compatibility for Python runtimes, as Python runtimes built on systems with newer kernels and glibc versions will depend on the getrandom syscall (for example, this can come up when running Fedora images on OpenShift for development purposes).
For additional background, see https://www.python.org/dev/peps/pep-0522/
(In reply to Nick Coghlan from comment #1)
> Just noting that this is likely to be important for userspace/kernel
> container compatibility for Python runtimes, as Python runtimes built on
> systems with newer kernels and glibc versions will depend on the getrandom
> syscall (for example, this can come up when running Fedora images on
> OpenShift for development purposes).
> For additional background, see https://www.python.org/dev/peps/pep-0522/
Thanks for the background. I'm trying to get consensus for adding a getrandom wrapper to glibc:
We would also like to be using this in krb5, though glibc support is not necessary for that use (similar to the python behavior: we both can go through syscall() to get functionality).
Stanislav, I think you just need to write a program to make the new getrandom system call.
(In reply to Herbert Xu from comment #7)
> Stanislav, I think you just need to write a program to make the new
> getrandom system call.
That seems doable, even though Hubert would probably like to test more :). Thanks for info.
Patch(es) committed on kernel repository and an interim kernel build is undergoing testing
Patch(es) available on kernel-3.10.0-544.el7
Please remove the reference to file descriptor exhaustion, and modify the last bit to say "and the kernel can now request randomness from the same non-blocking entropy pool usd by /dev/urandom, but to block until at least 128 bits of entropy has been accumulated in that pool."
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.