This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/17252] getrandom and getentropy syscall


https://sourceware.org/bugzilla/show_bug.cgi?id=17252

Nikos Mavrogiannopoulos <nmav at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nmav at redhat dot com

--- Comment #6 from Nikos Mavrogiannopoulos <nmav at redhat dot com> ---
There is a very long and interesting discussion at the thread above that is
very high level, but there is nothing to the point for this API. At the moment
the Linux kernel offers a new system call getrandom() which solves several
problems of /dev/urandom approach (see [0] for some affecting gnutls), but
userspace cannot access it in reasonable way. syscall() is not a reasonable
way.

To clarify; until now userspace is using autoconf macros to detect
capabilities, e.g., a function in libc, libwhatever. With the approach of
having useful kernel calls which don't map to libc we are unfortunately
breaking this detection and forcing them to do some compile/runtime detection
of system calls(?). That's pretty ugly.

My suggestion would be for glibc to duplicate the OpenBSD API [1], and not
provide any API for kernels without this capability (you can't duplicate these
semantics). The whole reason, for this system call is that the semantics of
/dev/urandom were too unreliable to simulate a getrandom() function.
Nevertheless, I wouldn't object in any other solution which brings the system
call.

I just believe that this system call to is too good to ignore for so long.

[0]. https://bugzilla.redhat.com/show_bug.cgi?id=1253474
[1].
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/getentropy.2?query=getentropy&sec=2

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]