Adding a system call wrapper for getrandom() in glibc would require adding an imperfect emulation in the event the kernel doesn't have getrandom() support. This means that the wrapper implementation is non-trivial. As such this issue is blocked on upstream consensus over adding the wrapper and how to handle it properly and if that means adding a BSD API on top of this.

Can't glibc simply require this system call from the kernel, or disable the code completely, i.e., no -ESYS, but rather not provide getrandom() at all?

(In reply to Nikos Mavrogiannopoulos from comment #2)
> Can't glibc simply require this system call from the kernel, or disable the
> code completely, i.e., no -ESYS, but rather not provide getrandom() at all?

I don't quite understand.  Do you want binaries which will eventually use the getrandom system call to fail to start on kernels which lack the system call?

I think this would negatively affect usage of the glibc interface because no library would want to use it.

I suppose that glibc is different in this regard from most of the other libraries as glibc is supposed to work reasonably (at least for some parts of its API) even when linked statically, etc. So yes, some kind of emulation would be probably needed for glibc.

That really means that crypto libraries should implement patches to call getrandom() directly as syscall for now for seeding their internal RNGs.

What we cannot expect is the overall use of getrandom() in the applications directly if it is not conveniently available in glibc (or at least some other general-purpose library such as glib).

(In reply to Florian Weimer from comment #3)
> (In reply to Nikos Mavrogiannopoulos from comment #2)
> > Can't glibc simply require this system call from the kernel, or disable the
> > code completely, i.e., no -ESYS, but rather not provide getrandom() at all?
> I don't quite understand.  Do you want binaries which will eventually use
> the getrandom system call to fail to start on kernels which lack the system
> call?

I was thinking something along the lines glibc after version X.Y requires a kernel with getrandom(). However, after Tomas' reply I now see your point and that may not be easy to do due to expectations of static linking.

However, is that reasonable? I mean if I compile a program which uses getrandom(), should I expect it to work flawlessly on a kernel without it?

(In reply to Nikos Mavrogiannopoulos from comment #5)
> (In reply to Florian Weimer from comment #3)
> > (In reply to Nikos Mavrogiannopoulos from comment #2)
> > > Can't glibc simply require this system call from the kernel, or disable the
> > > code completely, i.e., no -ESYS, but rather not provide getrandom() at all?
> > I don't quite understand.  Do you want binaries which will eventually use
> > the getrandom system call to fail to start on kernels which lack the system
> > call?
> 
> I was thinking something along the lines glibc after version X.Y requires a
> kernel with getrandom().

It will be a long time before upstream will start requiring a minimum kernel version of 3.17, perhaps some time between 2020 and 2025.

For internal use at Red Hat, Red Hat Enterprise Linux 7 has to remain compatible with kernel 2.6.32 for the foreseeable future.

Ok then I think it makes sense to provide a mockup of getrandom() if the system call isn't available. However, I don't see how you can make it fail safe. It may make sense to follow the getentropy() API and fail if /dev/urandom fd is closed and the device cannot be opened. I believe we can use the gcc attribute warn_unused_result to warn if the output of this function is not checked.

(in fact I'd really prefer if glibc would provide getentropy() and _not_ getrandom() so we can standardize that API across systems)
http://man.openbsd.org/OpenBSD-current/man2/getentropy.2

I should also mention explicitly that adding new APIs to the glibc ABI/API can't be done until RPM is upgraded to support finer grained symbol dependencies (this is the depend on bug 1320960).

This will be addressed in Red Hat Enterprise Linux 8.