gh-153400: Use kernel-provided __NR_getrandom syscall number

[jjhelmus]

Replace libc's SYS_getrandom with the kernel-provided __NR_getrandom in configure checks, os.getrandom(), and interpreter entropy handling.

This aligns with other syscall usage in the POSIX module.

This makes os.getrandom() available when building against an older glibc that was itself built with kernel headers lacking the syscall, provided the current kernel headers define __NR_getrandom. This type of build is done in python-build-standalone, astral-sh/python-build-standalone#1188.

• Issue: Resolve newer Linux os functions at runtime instead of compiling them out against old glibc #153400

[aisk]

Hi, I think this is not a trivial change, so the related issue is required.

[picnixz]

We changed to use the glibc-provided one in #155518 so I'm nt sure this change is needed anymore but maybe there is a world where neither glibc getrandom() exists nor SYS_getrandom in which case we need to fall back to __NR_getrandom.

cc @vstinner

[vstinner]

In the commit message, you can document that __NR_getrandom comes from Linux kernel <unistd.h>, whereas SYS_getrandom comes from glibc <sys/syscall.h>.

[vstinner]

This include should be removed, __NR_getrandom comes from <unistd.h> which is already included above.

__NR_getrandom comes the kernel header files, like /usr/include/asm/unistd_64.h on my Fedora 44. <sys/syscall.h> is the glibc header file which provides SYS_getrandom constant, but this change replace __NR_getrandom with SYS_getrandom.

[vstinner]

Suggested change

	#include <unistd.h> // __NR_getrandom

[vstinner]

Since SYS_getrandom is no longer used, <sys/syscall.h> include can be removed, no?

[vstinner]

Suggested change

	#include <linux/random.h> // GRND_NONBLOCK

[vstinner]

I don't know how Solaris, FreeBSD and OpenBSD expose their syscall numberes: __NR_getrandom or SYS_getrandom? The PR should be tested on these systems before being merged.

[jjhelmus]

We changed to use the glibc-provided one in #155518 so I'm nt sure this change is needed anymore but maybe there is a world where neither glibc getrandom() exists nor SYS_getrandom in which case we need to fall back to __NR_getrandom.

This is exactly the case that python-build-standalone is running into on x86-64. The target is glibc 2.17 which does not included getrandom and the Debian package providing it is built against a a kernel that does not include SYS_getrandom. The build uses a modern UAPI kernel heads so __NR_getrandom is available.

[vstinner]

This makes os.getrandom() available when building against an older glibc that was itself built with kernel headers lacking the syscall, provided the current kernel headers define __NR_getrandom.

Do you mean that glibc 2.17 doesn't provide SYS_getrandom macro?

[vstinner]

This is exactly the case that python-build-standalone is running into on x86-64. The target is glibc 2.17 which does not included getrandom and the Debian package providing it is built against a a kernel that does not include SYS_getrandom. The build uses a modern UAPI kernel heads so __NR_getrandom is available.

Which Linux kernel version are you used to build Python?

[jjhelmus]

Do you mean that glibc 2.17 doesn't provide SYS_getrandom macro?

Often not, glibc 2.17 was released in 2012. The the getrandom syscall was added to the kernel in 2014 with 3.17.
glibc generates syscall aliases from the kernel headers available when it is build, so if built against <3.17, the SYS_getrandom macro will not be included.

The specifics for python-build-standalone are glibc 2.19 build against kernel 3.16. So no getrandom function nor SYS_getrandom macro. Modern 7.0 UAPI kernel headers are used in the build so __NR_getrandom is available.

Note that the glib 2.17 packages in RHEL 9 and derivates likely include the macro because the syscall list was updated to include calls from the 5.4 kernel.

[vstinner]

Modern 7.0 UAPI kernel headers are used in the build so __NR_getrandom is available.

I don't know "UAPI kernel headers". How do they work?

[picnixz]

If we want to maximize compatibility I think we should rather check for both SYS_* and __NR_* macros then. Since we're anyway worrying about exotic platforms, we may even have the lack of __NR_* macro and getrandom() syscall and only the SYS_* macro.