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>
66300d6f40