runtime check for getrandom

[Tieske]

a comment by @o-lim:

Some users may build in containers or run/use pre-built binaries. This means the compile time version of glibc may not be the same as the runtime version, or the underlying kernel may not support getrandom() even though the glibc wrapper may be present. So if getrandom() returns an error with errno == ENOSYS, then the code should fallback to using /dev/urandom.

[Tieske]

considering the age of the older kernel (getrandom was introduced in kernel 3.17, which is from 2014). I'm tempted to leave this as is for now, and only fix it once we actually have someone hitting this problem.

Or do I then oversimplify? @o-lim @alerque

[o-lim]

considering the age of the older kernel (getrandom was introduced in kernel 3.17, which is from 2014). I'm tempted to leave this as is for now, and only fix it once we actually have someone hitting this problem.

Isn't that kind of the same as not supporting glibc < 2.25? Systems running these older glibc versions are probably also running old kernels (e.g. < 3.17) too. RHEL7/CentOs7 is on 3.8, and I think is still somewhat widely used.

For better compatibility, it would also be better to call the getrandom syscall directly rather than using the glibc wrapper.

[alerque]

@o-lim No it doesn't seem like quite the same thing. This new setup should work assuming you build and use the package on the same generation of system. As long as people don't download and install a binary rock built and packed on a newer system, the build should work on old kernels and glibc versions now. If the issue here is Ubuntu 16 LTS (I think that was the original use case) this just means you have to use LuaRocks on the host or a similar system to build the binary rock.

This is standard across thousands of apps, not just Lua. If you build on old glibc versions there is decent forward compatibility to run on new ones, but if you build something against new versions of glibc you cannot reliably run them on older systems. I don't see why this rock would need to special case an run time check that such a situation was not being encountered.

[o-lim]

Of course, if you build and use the library on the same system, then there's no issue. My point is for pre-built binaries. Plenty of open source projects provide their own pre-built binaries, and some even provide fairly broad compatibility, even for relatively old systems. That may not be the goal here, but simple fallbacks like this can help prevent future issues if/when those use cases arise. So easy fallbacks like this may be worth doing. If a pre-built use case is not really that realistic, then maybe it wouldn't really matter.

I some cases (e.g. Alpine), the glibc version macros may not be defined, but getrandom may still be supported. If the goal is to use getrandom when available, then the logic used to detect it would need some work for other less common distros.

[alerque]

Of course if making binary distributions widely portable was the goal, you'd be right. I just don't see how it's applicable enough to go to extra work for in this case.

Alpine has lua-system in their package manager so it will be built for the right system anyway. Adjusting the build-time logic to use the best available tool may make sense.

Ubuntu 16 also has it packaged, but doesn't have any update mechanism to bump the version in old system releases, so building it from scratch using luarocks is pretty much the only way anyone is going to get it. I don't know of any binary releases being done anywhere that Ubuntu 16.x folks might be even tempted to try.

None of this is to say you couldn't setup runtime detection too –or more robust build time options– but I would leave that up to whoever is willing to contribute it. Sure, add runtime check for getrandom(). But the build time logic change that was made was at least a step forward, not a step back.