The new test hooks allow to check whether there was an unsafe call of an
optionally safe function in the codepath. For the sake of simplicity the
MBEDTLS_MPI_IS_* macros are reused for signalling safe/unsafe codepaths
here too.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Generally speaking, in this group of test we use O_SRV when testing our
client's behaviour, and O_CLI when testing our server's behaviour. I
don't think that's essential, but why not.
Well, for these two tests there's a reason why not: O_CLI often exits 0,
seemingly not minding that the server aborted the handshake with a fatal
alert, but sometimes it exits 1. (I've observed 0 on my machine, on two
runs of OpenCI and Internal CI, and 1 in some test in one run of
Internal CI.)
So, use our client instead, which exits non-zero consistently.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
We were only testing the static key store (MBEDTLS_PSA_KEY_STORE_DYNAMIC
disabled) with configs/*.h. Add a component with the static key store and
everything else (including built-in keys), and a component with the static
key store and CTR_DBRG using PSA for AES (which means PSA uses a volatile
key internally).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add a practical way to fill the dynamic key store by artificially limiting
the slice length through a test hook.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
It's impractical to fill the key store when it can grow to accommodate
millions of keys.
A later commit will restore those tests in test configurations with the
dynamic key store.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Create a new compilation option for a dynamically resized key store. The
implementation will follow in subsequent commits.
This option is off by default with custom configuration files, which is best
for typical deployments on highly constrained platforms. This option is on
by default with the provided configuration file, which is best for typical
deployments on relatively high-end platforms.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
- cli-auth 1.2 was missing a test with an irrelevant bit set in addition
to the relevant bit (which was added for 1.3 previously)
- use consistent naming for fail (hard/soft)
Note: currently there are no "fail (soft)" cases for 1.3 authentication
of server by client, as server auth is mandatory in 1.3 (this will
change in 3.6.1).
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Previously the client was only printing them on handshake success, and
the server was printing them on success and some but not all failures.
This makes ssl-opt.sh more consistent as we can always check for the
presence of the expected message in the output, regardless of whether
the failure is hard or soft.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
- consistent naming with explicit version
- in each section, have a positive case with just the needed bit set,
and one with an irrelevant bit set in addition (cli 1.3 only had the
former, and cli-auth 1.3 only the later)
- when auth_mode optional is supported failing cases should come in
pairs: soft+hard, this wasn't the case for cli-auth 1.3. (Note: cli 1.3
currently does not support auth_mode optional.)
- failing cases should check that the correct flag is printed and the
expected alert is sent.
The last (two) points have uncovered a bug in 1.3 code:
- In fail (hard) cases the correct alert isn't send, but a more generic
one instead.
- In fail (soft) cases the issue with the certificate is not reported,
actually the certificate is reported as valid.
Both share the same root cause: the flags are not updated properly when
checking the keyUsage extension. This will be addressed in future
commits.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
In terms of line coverage, this was covered, except we never checked the
behaviour was as intended.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
* public/mbedtls-3.6: (251 commits)
Call in_mbedtls_repo
Move some proj detection code inside pre_check_environment
Match spacing in pointer types in documentation with the code style
Rename one more deprecated identifier
Documentation improvements
Rename internal function psa_key_production_parameters_are_default
key_custom: update analyze_outcomes.py
Test cpp_dummy_build in pedantic mode
Changelog entry for the move from key_ext to key_custom functions
Remove some tests of psa_generate_key_ext
Document the key_ext functions as deprecated
Documentation: point to key_custom instead of key_ext
Update PSA wrappers
Implement psa_generate_key_custom
all.sh/components: Removed components.sh
all.sh/components: Moved build_aes_via_padlock to platform component.
all.sh/components: Moved driver components to configuration crypto.
all.sh/components: Moved more components to configuration crypto.
all.sh/components: Fixed a typo in configuration-tls.
all.sh/components: Moved more components to configuration tls.
...
In public headers, we want to avoid things that are not standard C++,
including features that GCC and Clang support as extensions, such as
flexible array members. So compile with `-pedantic`.
Non-regression for https://github.com/Mbed-TLS/mbedtls/issues/9020.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
We know it's a thin wrapper around psa_generate_key_custom, so we just need
to check that it's passing the information through, we don't need coverage
of the parameter interpretation.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Implement `psa_generate_key_custom()` and
`psa_key_derivation_output_key_custom()`. These functions replace
`psa_generate_key_ext()` and `psa_key_derivation_output_key_ext()`.
They have the same functionality, but a slightly different interface:
the `ext` functions use a structure with a flexible array member to pass
variable-length data, while the `custom` functions use a separate parameter.
Keep the `ext` functions for backward compatibility with Mbed TLS 3.6.0.
But make them a thin wrapper around the new `custom` functions.
Duplicate the test code and data. The test cases have to be duplicated
anyway, and the test functions are individually more readable this way.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
