test: Add sanitizer suppressions for AMD EPYC CPUs #20844

Currently the ci system only runs on intel cpus (and some arm devices), but it won't run on CPUs Using the 'shani(1way,2way)' SHA256 implementation (excerpt from debug log).

For reference, google cloud CPUs (which is what Cirrus CI uses) print Using the 'sse4(1way),sse41(4way),avx2(8way)' SHA256 implementation

The traceback I got:

crypto/sha256_shani.cpp:87:18: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'size_t' (aka 'unsigned long')
    [#0](/bitcoin-bitcoin/0/) 0x55c0000e95ec in sha256_shani::Transform(unsigned int*, unsigned char const*, unsigned long) /root/bitcoin/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/crypto/sha256_shani.cpp:87:18
    [#1](/bitcoin-bitcoin/1/) 0x55bfffb926f8 in (anonymous namespace)::SelfTest() /root/bitcoin/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/crypto/sha256.cpp:517:9
    [#2](/bitcoin-bitcoin/2/) 0x55bfffb906ed in SHA256AutoDetect[abi:cxx11]() /root/bitcoin/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/crypto/sha256.cpp:626:5
    [#3](/bitcoin-bitcoin/3/) 0x55bfff87ab97 in BasicTestingSetup::BasicTestingSetup(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<char const*, std::allocator<char const*> > const&) /root/bitcoin/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/test/util/setup_common.cpp:104:5
    [#4](/bitcoin-bitcoin/4/) 0x55bffe885877 in main /root/bitcoin/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/qt/test/test_main.cpp:52:27
    [#5](/bitcoin-bitcoin/5/) 0x7f20c3bf60b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    [#6](/bitcoin-bitcoin/6/) 0x55bffe7a5f6d in _start (/root/bitcoin/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/qt/test/test_bitcoin-qt+0x1d00f6d)

SUMMARY: UndefinedBehaviorSanitizer: unsigned-integer-overflow crypto/sha256_shani.cpp:87:18 in

I think the unsigned integer overflow check is questionable in the first place. After all, unsigned integer overflow isn't UB and completely normal in cryptography and other bit manipulation code.

Anyhow ACK fa6c114ae604571435e8c4d25906a8b6d5b9984c

Post-merge ACK fa6c114ae604571435e8c4d25906a8b6d5b9984c: a general crypto/* suppression for unsigned-integer-overflow makes perfect sense!

Thanks for fixing this @MarcoFalke!

@laanwj

I think the unsigned integer overflow check is questionable in the first place. After all, unsigned integer overflow isn't UB and completely normal in cryptography and other bit manipulation code.

In fairness it is probably worth mentioning that the goal of the UBSan's unsigned-integer-overflow is not to catch UB: as you correctly point out there is no UB to catch when it comes to unsigned integers :)

The idea is instead to make reliance on wraparound semantics explicit by documenting in which areas of our code code we expect unsigned integer wraparounds to occur (such as in crypto/*).

UBSan can then flag all wraparounds outside of the expected areas: such cases are are likely unintentional (bugs).

Also, it should be noted that the list of unsigned-integer-overflow suppressions in test/sanitizer_suppressions/ubsan has remained largely static over time which suggests that this UBSan check is a very cheap way to kill this bug class (unintended unsigned integer wraparounds).