MBEDTLS_HAVE_ASM checks in check_config.h fire up on the wrong platforms

[gilles-peskine-arm]

In check_config.h, we have the following checks to error out if a requested library feature requires assembly code but the user has declared that the compiler doesn't support inline assembly:

#if defined(MBEDTLS_AESNI_C) && !defined(MBEDTLS_HAVE_ASM)
#error "MBEDTLS_AESNI_C defined, but not all prerequisites"
#endif

#if defined(MBEDTLS_AESCE_C) && !defined(MBEDTLS_HAVE_ASM)
#error "MBEDTLS_AESCE_C defined, but not all prerequisites"
#endif

#if defined(MBEDTLS_PADLOCK_C) && !defined(MBEDTLS_HAVE_ASM)
#error "MBEDTLS_PADLOCK_C defined, but not all prerequisites"
#endif

These checks are overly strict: MBEDTLS_AESNI_C, MBEDTLS_AESCE_C and MBEDTLS_PADLOCK_C have no effect when building for a target CPU architecture that doesn't support those features. More precisely, the corresponding module is empty on other architectures. For example, if you build for arm, you get the exact same binary (apart from mbedtls_strerror) whether MBEDTLS_AESNI_C is enabled or not; but if you disable MBEDTLS_HAVE_ASM, the build fails for no good reason.

This was raised in #7234 for AESCE when building on x86. It's in fact a preexisting issue with AESNI and Padlock when building on non-x86.

As a fix, we should only perform this check if the feature actually gets built. This means either:

• Gate the check in check_config.h on whether the feature actually gets built. This requires using the symbols MBEDTLS_HAVE_X86, MBEDTLS_HAVE_X86_64, MBEDTLS_HAVE_ARM64 (3.4+ only), which are currently defined in private headers in 3.x and in the respective public headers (aesni.h, padlock.h) in 2.28.
• Or move those checks into the library source file (aesce.c, aesni.c, padlock.c). This would avoid messing with publicly exposed symbols and would ensure that there's no inconsistency. I don't see any reason not to do that even in 2.28.

On a very related note, in aesni.c, there is a check that the configuration is consistent with build settings:

#if defined(__has_feature)
#if __has_feature(memory_sanitizer)
#warning \
    "MBEDTLS_AESNI_C is known to cause spurious error reports with some memory >
#endif
#endif

This check is in the wrong place: it should be gated by MBEDTLS_HAVE_X86_64.

Definition of done:

• A build with MBEDTLS_AESNI_C for a non-x86 target does not error out even if MBEDTLS_HAVE_ASM is disabled.
• A build with MBEDTLS_AESNI_C for a non-x86 target does not error out even when using Msan with GCC or Clang.
• A build with MBEDTLS_PADLOCK_C for a non-x86 target does not error out even if MBEDTLS_HAVE_ASM is disabled.