Merge pull request #8186 from paul-elliott-arm/fix_wrapper_deadcode Remove logically dead code
diff --git a/3rdparty/everest/CMakeLists.txt b/3rdparty/everest/CMakeLists.txt index eefc151..e0e5ade 100644 --- a/3rdparty/everest/CMakeLists.txt +++ b/3rdparty/everest/CMakeLists.txt
@@ -18,11 +18,11 @@ # everest is not directly linked against any mbedtls targets # so does not inherit the compile definitions. if(MBEDTLS_CONFIG_FILE) - target_compile_definitions(everest + target_compile_definitions(${everest_target} PUBLIC MBEDTLS_CONFIG_FILE="${MBEDTLS_CONFIG_FILE}") endif() if(MBEDTLS_USER_CONFIG_FILE) - target_compile_definitions(everest + target_compile_definitions(${everest_target} PUBLIC MBEDTLS_USER_CONFIG_FILE="${MBEDTLS_USER_CONFIG_FILE}") endif()
diff --git a/3rdparty/p256-m/CMakeLists.txt b/3rdparty/p256-m/CMakeLists.txt index 41be3c4..2ef0d48 100644 --- a/3rdparty/p256-m/CMakeLists.txt +++ b/3rdparty/p256-m/CMakeLists.txt
@@ -16,11 +16,11 @@ # p256m is not directly linked against any mbedtls targets # so does not inherit the compile definitions. if(MBEDTLS_CONFIG_FILE) - target_compile_definitions(p256m + target_compile_definitions(${p256m_target} PUBLIC MBEDTLS_CONFIG_FILE="${MBEDTLS_CONFIG_FILE}") endif() if(MBEDTLS_USER_CONFIG_FILE) - target_compile_definitions(p256m + target_compile_definitions(${p256m_target} PUBLIC MBEDTLS_USER_CONFIG_FILE="${MBEDTLS_USER_CONFIG_FILE}") endif()
diff --git a/ChangeLog.d/fix-3rdparty-target-prefix.txt b/ChangeLog.d/fix-3rdparty-target-prefix.txt new file mode 100644 index 0000000..db8ed07 --- /dev/null +++ b/ChangeLog.d/fix-3rdparty-target-prefix.txt
@@ -0,0 +1,3 @@ +Bugfix + * Fix accidental omission of MBEDTLS_TARGET_PREFIX in 3rdparty modules + in CMake.
diff --git a/docs/architecture/psa-thread-safety.md b/docs/architecture/psa-thread-safety.md index b0ca808..06bdcc0 100644 --- a/docs/architecture/psa-thread-safety.md +++ b/docs/architecture/psa-thread-safety.md
@@ -67,16 +67,32 @@ We may want to go directly to a more sophisticated approach because when a system works with a global lock, it's typically hard to get rid of it to get more fine-grained concurrency. +### Key destruction short-term requirements + +#### Summary of guarantees in the short term + +When `psa_destroy_key` returns: + +1. The key identifier doesn't exist. Rationale: this is a functional requirement for persistent keys: the caller can immediately create a new key with the same identifier. +2. The resources from the key have been freed. Rationale: in a low-resource condition, this may be necessary for the caller to re-create a similar key, which should be possible. +3. The call must not block indefinitely, and in particular cannot wait for an event that is triggered by application code such as calling an abort function. Rationale: this may not strictly be a functional requirement, but it is an expectation `psa_destroy_key` does not block forever due to another thread, which could potentially be another process on a multi-process system. In particular, it is only acceptable for `psa_destroy_key` to block, when waiting for another thread to complete a PSA Cryptography API call that it had already started. + +When `psa_destroy_key` is called on a key that is in use, guarantee 2. might be violated. (This is consistent with the requirement [“Correctness out of the box”](#correctness-out-of-the-box), as destroying a key while it's in use is undefined behavior.) + ### Key destruction long-term requirements -As noted above in [“Correctness out of the box”](#correctness-out-of-the-box), when a key is destroyed, it's ok if `psa_destroy_key` allows copies of the key to live until ongoing operations using the key return. In the long term, it would be good to guarantee that `psa_destroy_key` wipes all copies of the key material. +The [PSA Crypto API specification](https://armmbed.github.io/mbed-crypto/html/api/keys/management.html#key-destruction) mandates that implementations make a best effort to ensure that the key material cannot be recovered. In the long term, it would be good to guarantee that `psa_destroy_key` wipes all copies of the key material. -#### Summary of guarantees when `psa_destroy_key` returns +#### Summary of guarantees in the long term -* The key identifier doesn't exist. Rationale: this is a functional requirement for persistent keys: the caller can immediately create a new key with the same identifier. -* The resources from the key have been freed. Rationale: in a low-resource condition, this may be necessary for the caller to re-create a similar key, which should be possible. -* The call must not block indefinitely, and in particular cannot wait for an event that is triggered by application code such as calling an abort function. Rationale: this may not strictly be a functional requirement, but it is an expectation `psa_destroy_key` does not block forever due to another thread, which could potentially be another process on a multi-process system. -* In the long term, no copy of the key material exists. Rationale: this is a security requirement. We do not have this requirement yet, but we need to document this as a security weakness, and we would like to become compliant. +When `psa_destroy_key` returns: + +1. The key identifier doesn't exist. Rationale: this is a functional requirement for persistent keys: the caller can immediately create a new key with the same identifier. +2. The resources from the key have been freed. Rationale: in a low-resource condition, this may be necessary for the caller to re-create a similar key, which should be possible. +3. The call must not block indefinitely, and in particular cannot wait for an event that is triggered by application code such as calling an abort function. Rationale: this may not strictly be a functional requirement, but it is an expectation `psa_destroy_key` does not block forever due to another thread, which could potentially be another process on a multi-process system. In particular, it is only acceptable for `psa_destroy_key` to block, when waiting for another thread to complete a PSA Cryptography API call that it had already started. +4. No copy of the key material exists. Rationale: this is a security requirement. We do not have this requirement yet, but we need to document this as a security weakness, and we would like to satisfy this security requirement in the future. + +As opposed to the short term requirements, all the above guarantees hold even if `psa_destroy_key` is called on a key that is in use. ## Resources to protect
diff --git a/include/mbedtls/config_adjust_legacy_crypto.h b/include/mbedtls/config_adjust_legacy_crypto.h index 6ec59f1..495cd5a 100644 --- a/include/mbedtls/config_adjust_legacy_crypto.h +++ b/include/mbedtls/config_adjust_legacy_crypto.h
@@ -79,7 +79,7 @@ #define MBEDTLS_ECP_LIGHT #endif -/* MBEDTLS_PK_PARSE_EC_COMPRESSED is introduced in MbedTLS version 3.5, while +/* MBEDTLS_PK_PARSE_EC_COMPRESSED is introduced in Mbed TLS version 3.5, while * in previous version compressed points were automatically supported as long * as PK_PARSE_C and ECP_C were enabled. As a consequence, for backward * compatibility, we auto-enable PK_PARSE_EC_COMPRESSED when these conditions
diff --git a/library/pkcs12.c b/library/pkcs12.c index dd3a240..4db2a4b 100644 --- a/library/pkcs12.c +++ b/library/pkcs12.c
@@ -169,6 +169,7 @@ unsigned char iv[16]; const mbedtls_cipher_info_t *cipher_info; mbedtls_cipher_context_t cipher_ctx; + size_t iv_len = 0; size_t finish_olen = 0; unsigned int padlen = 0; @@ -196,9 +197,10 @@ } } + iv_len = mbedtls_cipher_info_get_iv_size(cipher_info); if ((ret = pkcs12_pbe_derive_key_iv(pbe_params, md_type, pwd, pwdlen, key, keylen, - iv, mbedtls_cipher_info_get_iv_size(cipher_info))) != 0) { + iv, iv_len)) != 0) { return ret; } @@ -208,9 +210,8 @@ goto exit; } - if ((ret = - mbedtls_cipher_setkey(&cipher_ctx, key, 8 * keylen, - (mbedtls_operation_t) mode)) != 0) { + if ((ret = mbedtls_cipher_setkey(&cipher_ctx, key, 8 * keylen, + (mbedtls_operation_t) mode)) != 0) { goto exit; } @@ -233,22 +234,8 @@ } #endif /* MBEDTLS_CIPHER_MODE_WITH_PADDING */ - if ((ret = - mbedtls_cipher_set_iv(&cipher_ctx, iv, - mbedtls_cipher_info_get_iv_size(cipher_info))) != 0) { - goto exit; - } - - if ((ret = mbedtls_cipher_reset(&cipher_ctx)) != 0) { - goto exit; - } - - if ((ret = mbedtls_cipher_update(&cipher_ctx, data, len, - output, output_len)) != 0) { - goto exit; - } - - if ((ret = mbedtls_cipher_finish(&cipher_ctx, output + (*output_len), &finish_olen)) != 0) { + ret = mbedtls_cipher_crypt(&cipher_ctx, iv, iv_len, data, len, output, &finish_olen); + if (ret == MBEDTLS_ERR_CIPHER_INVALID_PADDING) { ret = MBEDTLS_ERR_PKCS12_PASSWORD_MISMATCH; }
diff --git a/library/psa_crypto_pake.c b/library/psa_crypto_pake.c index 7a904d9..db00cbd 100644 --- a/library/psa_crypto_pake.c +++ b/library/psa_crypto_pake.c
@@ -304,10 +304,10 @@ #if defined(MBEDTLS_PSA_BUILTIN_ALG_JPAKE) /* - * The PSA CRYPTO PAKE and MbedTLS JPAKE API have a different + * The PSA CRYPTO PAKE and Mbed TLS JPAKE API have a different * handling of output sequencing. * - * The MbedTLS JPAKE API outputs the whole X1+X2 and X2S steps data + * The Mbed TLS JPAKE API outputs the whole X1+X2 and X2S steps data * at once, on the other side the PSA CRYPTO PAKE api requires * the KEY_SHARE/ZP_PUBLIC/ZK_PROOF parts of X1, X2 & X2S to be * retrieved in sequence. @@ -423,17 +423,17 @@ #if defined(MBEDTLS_PSA_BUILTIN_ALG_JPAKE) /* - * The PSA CRYPTO PAKE and MbedTLS JPAKE API have a different + * The PSA CRYPTO PAKE and Mbed TLS JPAKE API have a different * handling of input sequencing. * - * The MbedTLS JPAKE API takes the whole X1+X2 or X4S steps data + * The Mbed TLS JPAKE API takes the whole X1+X2 or X4S steps data * at once as input, on the other side the PSA CRYPTO PAKE api requires * the KEY_SHARE/ZP_PUBLIC/ZK_PROOF parts of X1, X2 & X4S to be * given in sequence. * * In order to achieve API compatibility, each X1+X2 or X4S step data * is stored sequentially in an intermediate buffer and given to the - * MbedTLS JPAKE API on the last step. + * Mbed TLS JPAKE API on the last step. * * This causes any input error to be only detected on the last step. */
diff --git a/programs/ssl/ssl_context_info.c b/programs/ssl/ssl_context_info.c index 855b091..9744c58 100644 --- a/programs/ssl/ssl_context_info.c +++ b/programs/ssl/ssl_context_info.c
@@ -1,5 +1,5 @@ /* - * MbedTLS SSL context deserializer from base64 code + * Mbed TLS SSL context deserializer from base64 code * * Copyright The Mbed TLS Contributors * SPDX-License-Identifier: Apache-2.0
diff --git a/scripts/code_size_compare.py b/scripts/code_size_compare.py index 53d859e..e764e9d 100755 --- a/scripts/code_size_compare.py +++ b/scripts/code_size_compare.py
@@ -901,7 +901,7 @@ '-c', '--config', type=str, default=SupportedConfig.DEFAULT.value, choices=list(map(lambda s: s.value, SupportedConfig)), help='Specify configuration type for code size comparison. ' - '(Default is the current MbedTLS configuration.)') + '(Default is the current Mbed TLS configuration.)') group_optional.add_argument( '--markdown', action='store_true', dest='markdown', help='Show comparision of code size in a markdown table. '
diff --git a/tests/scripts/all.sh b/tests/scripts/all.sh index 9e1d84f..7e6c95c 100755 --- a/tests/scripts/all.sh +++ b/tests/scripts/all.sh
@@ -1164,21 +1164,6 @@ tests/context-info.sh } -component_test_full_cmake_gcc_asan_new_bignum_test_hooks () { - msg "build: full config, cmake, gcc, ASan" - scripts/config.py full - scripts/config.py set MBEDTLS_TEST_HOOKS - scripts/config.py set MBEDTLS_ECP_WITH_MPI_UINT - CC=gcc cmake -D CMAKE_BUILD_TYPE:String=Asan . - make - - msg "test: main suites (inc. selftests) (full config, ASan build)" - make test - - msg "test: selftest (ASan build)" # ~ 10s - programs/test/selftest -} - component_test_psa_crypto_key_id_encodes_owner () { msg "build: full config + PSA_CRYPTO_KEY_ID_ENCODES_OWNER, cmake, gcc, ASan" scripts/config.py full
diff --git a/tests/scripts/audit-validity-dates.py b/tests/scripts/audit-validity-dates.py index 623fd23..5128dc7 100755 --- a/tests/scripts/audit-validity-dates.py +++ b/tests/scripts/audit-validity-dates.py
@@ -276,7 +276,7 @@ @staticmethod def find_test_dir(): - """Get the relative path for the MbedTLS test directory.""" + """Get the relative path for the Mbed TLS test directory.""" return os.path.relpath(build_tree.guess_mbedtls_root() + '/tests')
diff --git a/tests/scripts/check_names.py b/tests/scripts/check_names.py index f812929..86a7c09 100755 --- a/tests/scripts/check_names.py +++ b/tests/scripts/check_names.py
@@ -941,7 +941,7 @@ "This script confirms that the naming of all symbols and identifiers " "in Mbed TLS are consistent with the house style and are also " "self-consistent.\n\n" - "Expected to be run from the MbedTLS root directory.") + "Expected to be run from the Mbed TLS root directory.") ) parser.add_argument( "-v", "--verbose",
diff --git a/tests/scripts/test_psa_compliance.py b/tests/scripts/test_psa_compliance.py index 3590436..34b4494 100755 --- a/tests/scripts/test_psa_compliance.py +++ b/tests/scripts/test_psa_compliance.py
@@ -46,7 +46,7 @@ } # We currently use a fork of ARM-software/psa-arch-tests, with a couple of downstream patches -# that allow it to build with MbedTLS 3, and fixes a couple of issues in the compliance test suite. +# that allow it to build with Mbed TLS 3, and fixes a couple of issues in the compliance test suite. # These fixes allow the tests numbered 216, 248 and 249 to complete successfully. # # Once all the fixes are upstreamed, this fork should be replaced with an upstream commit/tag.
diff --git a/tests/suites/test_suite_pkcs12.data b/tests/suites/test_suite_pkcs12.data index c4e4d77..64c9991 100644 --- a/tests/suites/test_suite_pkcs12.data +++ b/tests/suites/test_suite_pkcs12.data
@@ -1,4 +1,4 @@ -PKCS#12 derive key : MD5: Zero length password and hash +PKCS#12 derive key: MD5: Zero length password and hash depends_on:MBEDTLS_MD_CAN_MD5 pkcs12_derive_key:MBEDTLS_MD_MD5:48:"":USE_GIVEN_INPUT:"":USE_GIVEN_INPUT:3:"6afdcbd5ebf943272134f1c3de2dc11b6afdcbd5ebf943272134f1c3de2dc11b6afdcbd5ebf943272134f1c3de2dc11b":0