We only enable SHA-256, so let's use that.
Previously the entropy module was deciding which hash to use based on
MBEDTLS_xxx_C feature macros, and since only SHA256_C was defined in
config_test_driver.h, it used that and things worked.
However since entropy was changed to use MD light, and
MBEDTLS_MD_CAN_xxx feature macros, we had an issue: when building
libtestdriver1 with its default config, MBEDTLS_PSA_ACCEL_ALG_SHA_512 is
defined even though there's no actual accelerator in the build. (This is
done so that PSA_WANT_ALG_SHA_512 can remain defined in order to match
the application's config, while not defining
MBEDTLS_PSA_BUILTIN_ALG_SHA_512 in order to only include what we need in
the build of libtestdriver1.) This will cause MD to dispatch to PSA in
order to take advantage of the accelerator, which will then fail because
there is no accelerator not builtin for this hash.
In the long-term, perhaps it would be best to address the root of the
issue: defining MBEDTLS_PSA_ACCEL_ALG_SHA_512 in a build that doesn't
actually have a SHA-512 accelerator is a lie. But that would require
significant changes in libtestdriver1. So for now, just fix the most
obvious symptom (picking a non-supported hash in entropy.h) by forcing
the choice of hash to match what's in the libtestdriver1 config.
Note: if the copy of entropy module in libtestdriver1 doesn't work,
we'll get a failure when calling libtestdriver1_psa_crypto_init(), which
we do, from mbedtls_test_transparent_init(), indirectly called by our
psa_crypto_init() which will then fail.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
These were assuming that psa_crypto_init() doesn't call hashes, which is
not always correct.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Split the part the varies between driver/built-in builds to a separate
file for convenience. Fix analyze_outcomes.py to be able to exclude
specific data files and not just a whole family at once.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
1. Change USE_PSA_CRYPTO_INIT/DONE to MD_OR_USE.
2. Add missing occurrences - some of these were already necessary in
principle (in one form or another) but where missing and this was not
detected so far as `psa_hash` doesn't complain in case of a missing
init, but now MD makes it visible.
3. Add missing include in ssl_test_lib.h.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Introduce MD_OR_USE_PSA_INIT/DONE. This will likely be used everywhere
in X.509 and SSL/TLS, but most places in PK only need USE_PSA_INIT/DONE.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
After this, only PK, X.509 and TLS remain to be done.
Deterministic uses HMAC-DRBG which uses MD, so it needs crypto_init()
when using a driver-only hash.
Also, remove a special-purpose macro that's no longer needed.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Could use MD_CAN, as both are equivalent when MBEDTLS_PSA_CRYPTO_C is
defined, but using PSA_WANT is preferable in a PSA context.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
As a consequence, MD_C is now enabled in component accel_hash_use_psa.
Fix guards in X.509 info function to avoid this causing a failure now.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
sed -i -f md.sed library/pkcs12.c tests/suites/test_suite_pkcs12.* include/mbedtls/pkcs12.h
with md.sed as before.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This enables access to all available hashes, instead of the previous
situation where you had to choose by including MD_C or not.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Note that ECC key derivation is not using drivers yet, as we don't have driver support for
cooked key derivation acceleration, see
https://github.com/Mbed-TLS/mbedtls/pull/5451 and follow-ups.
So, we still need MBEDTLS_ECP_C enabled at least for this, and probably
in several other places for now.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
