GNU Make 3.81 is officially not supported (we require >= 3.82), but be nice
to XCode users who are stuck with 3.81.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When PSA uses CTR_DRBG for its random generator and CTR_DRBG uses PSA for
AES, as currently implemented, there is one volatile key in permanent use
for the CTR_DRBG instance. Account for that in tests that want to know
exactly how many volatile keys are in use, or how many volatile keys can be
created.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When the PSA RNG uses AES through a PSA driver, it consumes one volatile key
identifier. When MBEDTLS_PSA_KEY_SLOT_DYNAMIC is enabled, that identifier
happens to coincide with the key ID value that the test case assumes not to
exist. Use a different value that avoids this coincidence.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Split the "many transient keys" test function in two: one that expects to
successfully create many keys, and one that expects to fill the key store.
This will make things easier when we add a dynamic key store where filling
the key store is not practical unless artificially limited.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The description was misleading: setting the option doesn't “restrict” the
number of slots, that restriction exists anyway. Setting the option merely
determines the value of the limit.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
PSA_KEY_ID_VOLATILE_MIN-1 is now in the persistent key ID range, so it's no
longer an invalid key ID for registration.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Fix interference between PSA volatile keys and built-in keys
when MBEDTLS_PSA_CRYPTO_BUILTIN_KEYS is enabled and
MBEDTLS_PSA_KEY_SLOT_COUNT is more than 4096. This overlap used to make it
possible that a volatile key would receive the identifier of a built-in key,
and is now caught by a static assertion.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Ensure that a key ID can't be in range for more than one of volatile keys,
persistent (i.e. user-chosen) keys or built-in keys.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Restricting the built-in key range would be an API break since applications
can hard-code a built-in key value and expect that it won't clash with
anything else. Make it harder to accidentally break the API.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
mbedtls_psa_register_se_key() is not usable with volatile keys, since there
is no way to return the implementation-chosen key identifier which would be
needed to use the key. Document this limitation. Reject an attempt to create
such an unusable key. Fixes#9253.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Make it possible, but not officially supported, to switch the CTR_DRBG
module to PSA mode even if MBEDTLS_AES_C is defined. This is not really
useful in practice, but is convenient to test the PSA mode without setting
up drivers.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
At the top level, the macro would have had to be used without a following
semicolon (except with permissive compilers that accept spurious semicolons
outside of a function), which is confusing to humans and indenters. Fix
that.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Remove the experimental functions psa_generate_key_ext() and
psa_key_derivation_output_key_ext(), which require a flexible array member
and therefore break C++ code that includes Mbed TLS headers. They have been
replaced by psa_generate_key_custom() and
psa_key_derivation_output_key_custom().
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
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>
Document psa_generate_key_ext() and psa_key_derivation_output_key_ext() as
deprecated in favor of psa_generate_key_custom() and
psa_key_derivation_output_key_custom(), and no longer declared in C++ builds.
Resolves#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>
Don't formally deprecate them because we don't do that in a
long-time support branch. But do point readers away from them.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Replace references to the deprecated functions `psa_generate_key_ext()` and
`psa_key_derivation_output_key_ext()` by their replacements
Implement `psa_generate_key_custom()` and
`psa_key_derivation_output_key_custom()`.
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>
