[Security-sig] Does the buildtime HAVE_GETRANDOM_SYSCALL check actually make sense?

Nick Coghlan ncoghlan at gmail.com
Sat Jun 25 16:36:55 EDT 2016

I think I've found a better explanation than mere timing or
coincidence for why we haven't had any problem reports regarding
Python 3.5.1 blocking in Fedora or in the Software Collections builds
for RHEL and CentOS: those builds currently aren't even trying to use
the new syscall, and are instead always using the older non-blocking
/dev/urandom behaviour.

My assumption in https://bugzilla.redhat.com/show_bug.cgi?id=1350123
is that this is due to those binaries being built against a version of
the kernel that doesn't have that syscall defined, which means the
config script doesn't define HAVE_GETRANDOM_SYSCALL, which means we
compile out the code that tries calling it at runtime.

Does skipping trying the new syscall at runtime just because the build
server is running an older kernel actually make sense? Or we would be
better off defining a different TRY_GETRANDOM_SYSCALL that looks for
some other indicator that this is a build for a platform where
getrandom() might be available at runtime, even if it's not available
at build time.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Security-SIG mailing list