Yet another fallback needed for getentropy :(
When building on a newer linux machine (glibc >= 2.25), the resulting binary will fail to run on an older one (<2.25), due to missing symbols. This adds a weak symbol for our own implementation for use as a last resort.
Alternative solutions welcome.
Alternative solutions welcome.
return 0? (aka, do nothing)
I assume we are already mixing /dev/urandom elsewhere though - if not, ACK
Alternative solutions welcome.
How about not using getentropy on Linux? It's a BSD compatibility function. The Really Good (TM) solution is using SYS_getrandom, but if that's not available, just fallback to using /dev/urandom directly.
I assume we are already mixing /dev/urandom elsewhere though.
No. getrandom / getentropy replace the need for /dev/urandom.
Just had a quick chat about this on IRC. I'll fix this up as discussed.
Huh? we should never be using getentropy() on Linux, that's why the getrandom() syscall is called directly. What is going wrong here exactly?
Edit: ok after discussion on IRC understand, getentropy is detected on newer versions of glibc, causing that to be used. That should be avoided, the SYS_getrandom path should always be used on Linux, getentropy is for BSD.
Additionally, ensure that getentropy uses the fallback in the event that it's
unsupported at runtime.
getentropy was added in glibc 2.25. This ensures that binaries linked against
later versions have a runtime fallback.
This fallback simply returns ENOSYS, indicating that /dev/urandom should be
used instead.
Updated as discussed with @sipa on IRC. @laanwj: specifically, the problem is building against a newer glibc, and older linux kernel headers for compatibility. So getentropy() is defined, but the syscall isn't. That's what I ran into here.
Would you like to explicitly disable getentropy for linux on the build side as well?
@theuni This commit simplifies the fallback logic a bit: https://github.com/sipa/bitcoin/commit/0abac37a1b3481ed7ab9ea2d0f7b32d819ea9964
Both this PR or just disabling getentropy on Linux are fine solutions to me.
Would you like to explicitly disable getentropy for linux on the build side as well?
I don't see why we'd need it. I made the syscall-based path for Linux to avoid having to rely on any function provided by glibc (e.g. to require a certain glibc version) for kernel randomness. But I don't care deeply, as long as it works...
utACK e596faf8efa211b3b17a555beba81a34dc68d55d. Unclear from discussion above whether there is agreement to continue allowing fallback to getentropy on linux, though IMO it makes the code cleaner to fall straight through all the available calls like this PR does (despite the need for the weak symbol workaround).
sipa's simplification https://github.com/sipa/bitcoin/commit/0abac37a1b3481ed7ab9ea2d0f7b32d819ea9964 also seems good.
Looking at this again with fresh eyes, I think the most straightforward is to only enable getentropy for openbsd, where we know what it's doing:
#elif defined(HAVE_GETENTROPY) && defined(__OpenBSD__)
Then we can drop all of the compat stuff. Sound reasonable?
Yes, sounds good to me.
Ok, closing this and opening a new PR as this no long has anything to do with back-compat.