An open source, portable, easy to use, readable and flexible TLS library, and reference implementation of the PSA Cryptography API. Releases are on a varying cadence, typically around 3 - 6 months between releases.
[ ] Change component_test_memsan_constant_flow to disable HAVE_ASM (which should disable all assembly everywhere: bignum, constant_time.c, etc. - we might still need to manually disable AESNI_C).
[ ] Add a check in check_config.h that complains about HAVE_ASM with memsan (see the check in aesni.c for inspiration - see also the existing MBEDTLS_HAS_MEMSAN in check_config.h).
[ ] Change component_test_valgrind_constant_flow to test both with and without HAVE_ASM. (Or if that's considered too much for CI load, only without HAVE_ASM - if we wrote assembly by hand, hopefully we knew what we were doing, while with C code it's fundamentally impossible to predict how future compiler will translate it.)
[ ] Then remove the hack in library/constant_time_impl.h so that it just predictably obeys HAVE_ASM instead of making fancy and possibly surprising decisions based on how it's being tested.
Once this task is completed, there should be no occurrence of MBEDTLS_TEST_CONSTANT_FLOW_ under library except for version_features.c. (We may want to add a check for that, with a reminder of the reason.)
Justification
Library modules should not modify which implementation they select based on how they're being tested. We need predictability in what exactly it is that we are testing.
Suggested enhancement
component_test_memsan_constant_flowto disableHAVE_ASM(which should disable all assembly everywhere:bignum,constant_time.c, etc. - we might still need to manually disableAESNI_C).check_config.hthat complains aboutHAVE_ASMwith memsan (see the check inaesni.cfor inspiration - see also the existingMBEDTLS_HAS_MEMSANincheck_config.h).component_test_valgrind_constant_flowto test both with and withoutHAVE_ASM. (Or if that's considered too much for CI load, only withoutHAVE_ASM- if we wrote assembly by hand, hopefully we knew what we were doing, while with C code it's fundamentally impossible to predict how future compiler will translate it.)library/constant_time_impl.hso that it just predictably obeysHAVE_ASMinstead of making fancy and possibly surprising decisions based on how it's being tested.Once this task is completed, there should be no occurrence of
MBEDTLS_TEST_CONSTANT_FLOW_underlibraryexcept forversion_features.c. (We may want to add a check for that, with a reminder of the reason.)Justification
Library modules should not modify which implementation they select based on how they're being tested. We need predictability in what exactly it is that we are testing.