Improvement: Skip rdrand tests if the CPU does not support them

[mikatammi]

Currently if you run "rdrand" tests and the CPU platform does not support hwrand, the tests just fail. Could we improve this, so that if the CPU being used does not support the feature, the test would be simply skipped?

I'm doing maintenance for the NixOS package NixOS/nixpkgs#472498 , and I was going to enable all the testcases again, but I still need to skip these specific tests if the package is being built on aarch64-linux platform as the NixOS CI build infrastructure uses arm64-linux builder which does not seem to support it. aarch64-darwin seems to be fine though.

Maybe somehow from the testcase we could call the same function Botan::Processor_RNG::available() that is called from here: https://github.com/randombit/botan/blob/master/src/lib/ffi/ffi_rng.cpp#L51 . Or implement some other kind of check

rdrand
  rngInit [✘]
  rngGet [✘]
  rngReseed [✘]
  rngReseedFromRNGCtx [✘]
  rngAddEntropy [✘]

Failures:

  test/Botan/Low/RNGSpec.hs:23:9:
  1) rdrand rngInit
       uncaught exception: SomeBotanException
       NotImplementedException (-40) "" [("throwBotanIfNegative_",SrcLoc {srcLocPackage = "botan-low-0.0.2.0-G4WRDaW90LG>

  To rerun use: --match "/rdrand/rngInit/" --seed 2066260477

  test/Botan/Low/RNGSpec.hs:26:9:
  2) rdrand rngGet
       uncaught exception: SomeBotanException
       NotImplementedException (-40) "" [("throwBotanIfNegative_",SrcLoc {srcLocPackage = "botan-low-0.0.2.0-G4WRDaW90LG>

  To rerun use: --match "/rdrand/rngGet/" --seed 2066260477

  test/Botan/Low/RNGSpec.hs:30:9:
  3) rdrand rngReseed
       uncaught exception: SomeBotanException
       NotImplementedException (-40) "" [("throwBotanIfNegative_",SrcLoc {srcLocPackage = "botan-low-0.0.2.0-G4WRDaW90LG>

  To rerun use: --match "/rdrand/rngReseed/" --seed 2066260477

  test/Botan/Low/RNGSpec.hs:34:9:
  4) rdrand rngReseedFromRNGCtx
       uncaught exception: SomeBotanException
       NotImplementedException (-40) "" [("throwBotanIfNegative_",SrcLoc {srcLocPackage = "botan-low-0.0.2.0-G4WRDaW90LG>

  To rerun use: --match "/rdrand/rngReseedFromRNGCtx/" --seed 2066260477

  test/Botan/Low/RNGSpec.hs:39:9:
  5) rdrand rngAddEntropy
       uncaught exception: SomeBotanException
       NotImplementedException (-40) "" [("throwBotanIfNegative_",SrcLoc {srcLocPackage = "botan-low-0.0.2.0-G4WRDaW90LG>

  To rerun use: --match "/rdrand/rngAddEntropy/" --seed 2066260477

[jorisdral]

Sure, we could probably improve this behaviour! I'd probably prefer changing the test success condition based on the platform it runs on, rather than skipping it, but I think we can otherwise do this in rather straightforward way with a bit of CPP

EDIT: hmm.. actually I think it might not be so straightforward as I initially thought. If we want to change the test success condition based on the OS, then that is straightforward. If we want to change it based on the BOTAN_HAS_PROCESSOR_RNG macro flag, then that would require a bit more work. If Botan::Processor_RNG::available() is the thing we want to call, then that is currently not possible (I think). I'll need to investigate a bit more

[mikatammi]

I actually made a PR to botan to add support for ARMv8.5-A FEAT_RNG extension. randombit/botan#5228

This won't fix the situation on Macs though because at least the M3 Max does not seem to support the FEAT_RNG, also with Linux you need to be running on very modern ARM64 core

[mikatammi]

https://github.com/randombit/botan/blob/master/src/tests/test_rng_behavior.cpp#L827-L861
Here's how it is done in the botan's tests. If the Processor_RNG::available() returns false, then it is expected to throw an exception in the testcase.

[jorisdral]

https://github.com/randombit/botan/blob/master/src/tests/test_rng_behavior.cpp#L827-L861 Here's how it is done in the botan's tests. If the Processor_RNG::available() returns false, then it is expected to throw an exception in the testcase.

Do you have an idea why it has to perform a dynamic check by calling available() rather than using a static check using a macro?

[mikatammi]

It is still possible to compile in the assembly instruction, and still run the program on a CPU which does not support the specific extension

[jorisdral]

Right, I think I'll try to add some CPP to conditionally disable the test based on macros like:

[mikatammi]

Yes. At this point it might be good idea to restrict running it to x86_64 and powerpc architectures, if you don't want find a way to call the dynamic checking function

Darwin/macOS running on x86_64 should still work because it has the rdrand instruction because of Intel, although Apple has already started phasing out x86_64 support for macOS, the current macOS 26.x Tahoe will likely be the last macOS that will run on x86_64 based machines