Created attachment 1062783 [details] getrandom code 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. For example the lines of code needed to seed the gnutls PRNG drops from 86 to 26 in as shown below: https://gitlab.com/gnutls/gnutls/blob/master/lib/nettle/rnd-common.c#L151 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.
*** This bug has been marked as a duplicate of bug 1172273 ***
I will comment on why this can't be done in non-Rawhide Fedora. To do so would create a glibc that has a new symbol not present in older Fedora glibc (still the same release). Applications might accidentally use the new symbol without knowing it, and fail to work on other Fedora installs (same release). You could fix that for your own package because you could use "Requires: glibc > X.Y.Z", but others might not notice that. Therefore as a rule, the core runtime ABI/API is fixed at release (GA). We could add "getrandom" in Rawhide, but Rawhide is directly a rebase of upstream, therefore this needs to go upstream (as mentioned in bug 1172273).
(In reply to Carlos O'Donell from comment #2) > I will comment on why this can't be done in non-Rawhide Fedora. To do so > would create a glibc that has a new symbol not present in older Fedora glibc > (still the same release). Applications might accidentally use the new symbol > without knowing it, and fail to work on other Fedora installs (same > release). You could fix that for your own package because you could use > "Requires: glibc > X.Y.Z", but others might not notice that. Therefore as a > rule, the core runtime ABI/API is fixed at release (GA). We could add > "getrandom" in Rawhide, but Rawhide is directly a rebase of upstream, > therefore this needs to go upstream (as mentioned in bug 1172273). The current problem is however even worse. Applications are expected to check for the presence of a system call number, not really a libc function to detect that capability. That's unlikely anything we have been doing until now. I see a very generic thread on libc-alpha on adding kernel interfaces in general but it seems like this discussion is leading nowhere. Until now if the kernel offered a system call we had a libc wrapper. Why has that to change now? Should we document into manuals our great syscall() interface?
(In reply to Nikos Mavrogiannopoulos from comment #3) > The current problem is however even worse. Applications are expected to > check for the presence of a system call number, not really a libc function > to detect that capability. That's unlikely anything we have been doing until > now. I see a very generic thread on libc-alpha on adding kernel interfaces > in general but it seems like this discussion is leading nowhere. If the Fedora kernel adds syscalls and applications tie themselves to requiring a particular syscall, then it is exactly the same problem as adding new API/ABIs. The kernel controls it's own policy, so they may do as they wish, but such behaviour on both the kernel and application side will break applications that subsequently depend on these features and expect to run on earlier systems than they were built upon (builder is newer than target system). > Until now if the kernel offered a system call we had a libc wrapper. Why has > that to change now? Should we document into manuals our great syscall() > interface? This is not true at all. The upstream glibc project has on occassion updated glibc to provide system call wrappers and there was no direct consensus on this issue. It appears that consensus will be reached around adding all of the linux syscalls, but the implementation details will be not what you expect (libc.so.6 will have those syscalls considered OS-independent, while libinux-syscalls.so.N will likely be included transparently and provide all the other syscalls).