Bug 1329996 (rhel7-getrandom)

Summary:	getrandom call missing in glibc
Product:	Red Hat Enterprise Linux 7	Reporter:	Nikos Mavrogiannopoulos <nmavrogi>
Component:	glibc	Assignee:	glibc team <glibc-bugzilla>
Status:	CLOSED NEXTRELEASE	QA Contact:	qe-baseos-tools-bugs
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	7.4	CC:	amit.shah, arjun, ashankar, codonell, eblake, extras-qa, fweimer, hannsj_uhl, hkario, jakub, law, mnewsome, nmavrogi, pfrankli, rharwood, tmraz, vinschen
Target Milestone:	rc	Keywords:	Patch
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	1172273	Environment:
Last Closed:	2018-11-20 09:42:22 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1172273, 1320960, 1330000, 1432218
Bug Blocks:	1411345

Description Nikos Mavrogiannopoulos 2016-04-25 09:04:17 UTC

+++ This bug was initially created as a clone of Bug #1172273 +++

Description of problem:
Libc doesn't contain a function to correspond to the getrandom() system call [0]. That is a very useful system call from cryptographic or for applications that need unpredictable numbers. That system call allows the simplification of heavily complicated code using /dev/urandom and avoids flaws of /dev/urandom such as providing randomness prior to kernel having completed its seeding.

For example the lines of code needed to seed the gnutls PRNG drops from 86 to 26.

That simplification also results to safer code. In the example above the checks to verify that the file descriptor didn't close due to some application code (e.g., some applications close all file descriptors on startup invalidating descriptors opened on a library constructor) are completely eliminated.

Please introduce that system call in libc.

[0]. http://lwn.net/Articles/606141/

How reproducible:
A program is attached which uses the getrandom() call. If compiled it results to:
getrandom.c:(.text+0x35): undefined reference to `getrandom'

Expected results:
It should have linked properly.

Comment 1 Carlos O'Donell 2016-04-25 18:14:51 UTC

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.

Comment 2 Nikos Mavrogiannopoulos 2016-04-26 07:20:23 UTC

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?

Comment 3 Florian Weimer 2016-04-26 08:11:49 UTC

(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.

Comment 4 Tomas Mraz 2016-04-26 08:21:55 UTC

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).

Comment 5 Nikos Mavrogiannopoulos 2016-04-26 08:41:35 UTC

(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?

Comment 6 Florian Weimer 2016-04-26 08:49:20 UTC

(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.

Comment 7 Nikos Mavrogiannopoulos 2016-04-26 08:55:22 UTC

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

Comment 8 Carlos O'Donell 2016-09-10 03:04:25 UTC

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).

Comment 13 Florian Weimer 2018-11-20 09:42:22 UTC

This will be addressed in Red Hat Enterprise Linux 8.