CI regression from the new hashtable support

[t8m]

2 CI on-push jobs have regressed.

run-checker (enable-asan enable-ubsan no-shared no-asm -DOPENSSL_SMALL_FOOTPRINT)

# ../../fuzz/corpora/hashtable/750489b928c4012a6c4352fdefd92c33d5ca600d
fuzz/hashtable.c:145:14: runtime error: load of misaligned address 0x602000000111 for type 'uint16_t' (aka 'unsigned short'), which requires 2 byte alignment
0x602000000111: note: pointer points here
 00 00 00  ce ce ce ce ce ce c4 ce  3f 3f 28 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00
              ^ 
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior fuzz/hashtable.c:145:14 in 
../../util/wrap.pl ../../fuzz/hashtable-test ../../fuzz/corpora/hashtable => 1
not ok 2 - Fuzzing hashtable
# ------------------------------------------------------------------------------
#   Failed test 'Fuzzing hashtable'
#   at ../../test/recipes/fuzz.pl line 22.

cross-compilation (hppa-linux-gnu, libc6-dev-hppa-cross, -static linux-generic32, no, -test_inclu...

../../util/wrap.pl ../../test/lhash_test => 139
not ok 1 - running lhash_test
# ------------------------------------------------------------------------------
#   Failed test 'running lhash_test'
#   at /home/runner/work/openssl/openssl/util/perl/OpenSSL/Test/Simple.pm line 77.
# Looks like you failed 1 test of 1.02-test_lhash.t ......................... 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests 

[t8m]

@nhorman Unfortunately the hppa cross-compile job is still not fixed:

https://github.com/openssl/openssl/actions/runs/8893580037/job/24420072833

[nhorman]

will look at it, need to get a local reproducer setup

[nhorman]

Notes:
So....this is troubling
while looking for the root cause of this issue, I found that it was occuring in the test_hashtable_multithread test. Its really odd, because it appears we're getting random memory corruption during the test

Whats more odd is that hppa is built without thread support, so its all single threaded, which eliminates race conditions as a possible source of the problem.

Whats more odd is that, in this single threaded environment

Whats more odd is that if I reduce the optimization level to -O1, the problem abates

further reading shows that pa-risc has no hardware support for atomics, all atomic operations are by default implemented with the sync library, or optionally by libatomic. When using the latter several build errors are produced, so for now we appear stuck with the former

I'm starting to wonder if perhaps we're seeing a issue with atomic operations on an old arch that isn't as well maintained anymore

[t8m]

Hmm... I am wondering if we should just have much more simple fallback for atomics on no-thread builds? Of course another option is to just declare this platform unsupported and remove it from CI.

[nhorman]

Possibly. I'd like to better understand the issue before we make a decision, but yeah, I think both of those options are on the table. It's also feasible that this is a compiler issue. One of the options for hppas compiler is -mnoindex-loads, which eliminates the use of indexed addressing mode in loads/stores to which this problem seems related to. Will let you know

[nhorman]

I'm becoming increasingly convinced that this is a compiler bug.

My observations so far:

• Crashes happen in multiple places randomly (sometimes in do_mt_hash_work, sometimes in CRYPTO_atomic_add, sometimes in various other locations), but always as a subordonate of do_mt_hash_work
• The crashes happen normally because a register that holds the value needed for an indirect load is garbage
• Inspecting with gdb shows those registers always hold the result of an indexed load
• setting optimization for the function do_mt_hash_work to O1 makes the problem abate

Its also notable that this isn't a race condition as hppa build disables threading

[t8m]

Then add -O1 or something else that fixes the issue here as workaround:

openssl/.github/workflows/cross-compiles.yml

Line 71 in 1848c56

target: -static linux-generic32,