Cannot switch off OQS_HAVE_GETENTROPY, OQS_HAVE_EXPLICIT_BZERO

[marcbrevoort-cyberhive]

When linking against OQS for armv6, I've been experiencing issues with undefined references for symbols __explicit_bzero and 'getentropy'. This is down to using rpi_tools for linking (pretty much required to build this for armv6), but unfortunately this only provides gcc v4.9.3 which is too low a version to compile OQS, so I end up with a mixed toolchain. As a result, cmake thinks these symbols will be available during link time, but they're not.

It appears the code caters for this eventuality, and contains both checks and fallback code depending on whether OQS_HAVE_GETENTROPY and OQS_HAVE_EXPLICIT_BZERO are defined. There's even a mechanism to switch these values to ON /defined, but unfortunately there doesn't seem to be a way to undefine these.

As a workaround, I'm now patching CMakeLists.txt by commenting out the symbol checks:

# patch CMakeLists file so "getentropy" and "explicit_bzero" are undefined
sed -i 's/check_symbol_exists[\(]getentropy/#check_symbol_exists(getentropy/' src/common/CMakeLists.txt
sed -i 's/check_symbol_exists[\(]explicit_bzero/#check_symbol_exists(explicit_bzero/' src/common/CMakeLists.txt

This allows me to complete my builds, but I'd much rather do this via an environment variable or
-DOQS_HAVE_GETENTROPY=OFF / -DOQS_HAVE_EXPLICIT_BZERO=OFF settings. Sadly this doesn't work.

Both code snippets use #if defined(....), perhaps this could check for the value of the variables instead?

[baentsch]

but unfortunately there doesn't seem to be a way to undefine these.

By default they should be undefined by default if my quick code review is correct.

This allows me to complete my builds, but I'd much rather do this via an environment variable or
-DOQS_HAVE_GETENTROPY=OFF / -DOQS_HAVE_EXPLICIT_BZERO=OFF settings. Sadly this doesn't work.

Making the defines user settable via cmake option surely would be possible, but looking at the code setting these e.g. here it seems intentional to not have this manually settable as it's driven by a symbol found (or not). So it seems our current logic is flawed in your setup: Could you pinpoint why (the define gets set)? Would you possibly have a suggestion what to change in this CMakeLists.txt file to cater for your case?

[baentsch]

@marcbrevoort-cyberhive Any input re my questions above? Or is the issue not relevant to you any longer and shall we close it?

[marcbrevoort-cyberhive]

Let me dig that one up again - due to the sed workaround it had slipped off-radar.