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