In client-side code with MBEDTLS_USE_PSA_CRYPTO, use the buffer size to
validate what is written in handshake->xxdh_psa_peerkey. The previous code
was correct, but a little fragile to misconfiguration or maintenance.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Fix a buffer overflow in TLS 1.2 ClientKeyExchange parsing. When
MBEDTLS_USE_PSA_CRYPTO is enabled, the length of the public key in an ECDH
or ECDHE key exchange was not validated. This could result in an overflow of
handshake->xxdh_psa_peerkey, overwriting further data in the handshake
structure or further on the heap.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Fix a buffer overflow in TLS 1.3 ServerHello and ClientHello parsing. The
length of the public key in an ECDH- or FFDH-based key exchange was not
validated. This could result in an overflow of handshake->xxdh_psa_peerkey,
overwriting further data in the handshake structure or further on the heap.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
These do not link directly against Mbed TLS so need their own
propagation of the custom config values through CMake.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
It was jumping directly to "driver support" and omitting the first step
of "PSA support".
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
MBEDTLS_TARGET_PREFIX is prepended to the CMake targets for Mbed TLS
except for targets in 3rdparty. Change this so that 3rdparty targets use
the prefix as well.
This allows multiple copies of Mbed TLS to be used in the same CMake
tree when using code in the 3rdparty directory.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
These are build-only components so this was never supported for sure.
Let's stick to what's really tested for now, and expand later (with
proper testing!) if there's demand for more flexibility.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Manual test: run test_psa_crypto_config_accel_ecc_non_weierstrass_curves
or test_psa_crypto_config_accel_ecc_weierstrass_curves as they are now,
observe it failing with the expected #error.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Tested manually as follows: in
component_test_psa_crypto_config_accel_ecc_some_key_types, modify
loc_accel_list to remove one of the key types between
helper_libtestdriver1_make_drivers and helper_libtestdriver1_make_main,
and observe that the 2nd build fails with the expected #error.
Note: removing one of the key types before
helper_libtestdriver1_make_drivers causes the build of libtestdriver1 to
fail, which is quite acceptable, just not what we're trying to observe.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Latest changes:
- logic about the relationship between curves, key types and algs (8075)
- building without bignum is no longer "coming soon", it's there :)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
These were temporaries to avoid unwanted use of low-level modules. Now
that we have test components with those modules fully disabled (replaced
with drivers), we no longer need these tests - which were out of date
too.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
There was a bit of a race condition between #8041 which introduced the
new entry points, and #8203 which documented the list of entry points.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Restore guards from the previous release, instead of the new, more
permissive guards.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
