CMake build broken with custom config using p256-m or everest

[gilles-peskine-arm]

Summary

When using CMake, the build fails when using a “3rdparty” feature (everest, p256-m) that is activated by any means other than editing include/mbedtls/mbedtls_config.h:

• because the build has a different mbedtls/mbedtls_config.h earlier in the include path;
• or the build defines MBEDTLS_CONFIG_FILE;
• or the build defines MBEDTLS_USER_CONFIG_FILE;
• or the options are enabled directly on the compiler command line.

Details

Steps to reproduce:

mkdir build-p256m-cmake
cd build-p256m-cmake
CFLAGS='-Wall -Wextra -DMBEDTLS_PSA_CRYPTO_CONFIG -DMBEDTLS_P256M_EXAMPLE_DRIVER_ENABLED' cmake ..

Expectation: the build succeeds.

Actual result: a linking failure, because the files in 3rdparty/p256-m are not built or linked.

… (no mention of 3rdparty) …
[ 20%] Building C object programs/aes/CMakeFiles/crypt_and_hash.dir/crypt_and_hash.c.o
[ 20%] Linking C executable crypt_and_hash
/usr/bin/ld: ../../library/libmbedcrypto.a(psa_crypto_driver_wrappers.c.o): in function `psa_driver_wrapper_sign_hash':
/home/gilpes01/z/dev/mbedtls/work/p256-m-zeroize/build-p256m-cmake/library/psa_crypto_driver_wrappers.c:319: undefined reference to `p256_transparent_sign_hash'
/usr/bin/ld: ../../library/libmbedcrypto.a(psa_crypto_driver_wrappers.c.o): in function `psa_driver_wrapper_verify_hash':
/home/gilpes01/z/dev/mbedtls/work/p256-m-zeroize/build-p256m-cmake/library/psa_crypto_driver_wrappers.c:423: undefined reference to `p256_transparent_verify_hash'
/usr/bin/ld: ../../library/libmbedcrypto.a(psa_crypto_driver_wrappers.c.o): in function `psa_driver_wrapper_generate_key':
/home/gilpes01/z/dev/mbedtls/work/p256-m-zeroize/build-p256m-cmake/library/psa_crypto_driver_wrappers.c:854: undefined reference to `p256_transparent_generate_key'
/usr/bin/ld: ../../library/libmbedcrypto.a(psa_crypto_driver_wrappers.c.o): in function `psa_driver_wrapper_key_agreement':
/home/gilpes01/z/dev/mbedtls/work/p256-m-zeroize/build-p256m-cmake/library/psa_crypto_driver_wrappers.c:2849: undefined reference to `p256_transparent_key_agreement'
collect2: error: ld returned 1 exit status
make[2]: *** [programs/aes/CMakeFiles/crypt_and_hash.dir/build.make:136: programs/aes/crypt_and_hash] Error 1
make[1]: *** [CMakeFiles/Makefile2:966: programs/aes/CMakeFiles/crypt_and_hash.dir/all] Error 2
make: *** [Makefile:146: all] Error 2

The problem is visible in 3rdparty/CMakeLists.txt: the subdirectories are only traversed if

execute_process(COMMAND ${MBEDTLS_PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/../scripts/config.py -f ${CMAKE_CURRENT_SOURCE_DIR}/../include/mbedtls/mbedtls_config.h get MBEDTLS_ECDH_VARIANT_EVEREST_ENABLED RESULT_VARIABLE everest_result)
execute_process(COMMAND ${MBEDTLS_PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/../scripts/config.py -f ${CMAKE_CURRENT_SOURCE_DIR}/../include/mbedtls/mbedtls_config.h get MBEDTLS_P256M_EXAMPLE_DRIVER_ENABLED RESULT_VARIABLE p256m_result)

This only works if the configuration is the one in include/mbedtls/mbedtls_config.h. It doesn't work when the respective options are enabled because the build has a different mbedtls/mbedtls_config.h earlier in the include path, or the build defines MBEDTLS_CONFIG_FILE, or the build defines MBEDTLS_USER_CONFIG_FILE, or the options are enabled directly on the compiler command line.

A tempting fix is to traverse the 3rdparty directories unconditionally, but I don't know if that causes some breakage (why didn't we do that in the first place?).

[gilles-peskine-arm]

Note: this affected TF-M, because they use MBEDTLS_CONFIG_FILE and cmake. A consequence for them is that when p256-m does an ECDSA signature, it calls psa_generate_random, and this tries to do a cross-partition call because crypto_spe.h is not included because p256-m is getting the wrong mbedtls configuration without MBEDTLS_PSA_CRYPTO_SPM.