Backport 3.6: md: allow dispatch to PSA whenever CRYPTO_CLIENT is enabled

[valeriosetti]

Description

Instead of allowing PSA dispatching only when CRYPTO_C is set and some MBEDTLS_PSA_ACCEL_ALG_xxx is set, we enable dispatching when CRYPTO_CLIENT and PSA_WANT_ALG_xxx are set. This makes the feature more useful in cases where the PSA support is provided externally, like for example TF-M in Zephyr.

PR checklist

• changelog provided
• development PR not required because crypto only
• crypto PR [tf-psa-crypto] md: allow dispatch to PSA whenever CRYPTO_CLIENT is enabled TF-PSA-Crypto#188
• framework PR [Framework] md: allow dispatch to PSA whenever CRYPTO_CLIENT is enabled mbedtls-framework#140
• 3.6 PR here
• 2.28 PR not required because new feature
• tests not required because this only affects client-server builds which are only unofficially supported and a known test gap in 3.6

[valeriosetti]

@mpg I took the liberty to add you as reviewer because you were the one who improved MD last year, allowing for the PSA dispatch, and we also discussed about this change in Slack. However if you don't have enough review bandwidth for this, please let me know and I'll remove you ;)

[valeriosetti]

The ABI-API break is expected because struct mbedtls_md_context_t will change its size depending on PSA_WANT_ instead of MBEDTLS_PSA_ACCEL_ symbols.

[valeriosetti]

CI green (a part from the ABI-API failure mentioned above), so I think the PR is ready for reviews

[mpg]

• changelog TBD, but I would like to have some feedback from reviewers about this change before doing it.

IMO not ChangeLog for this, as support for CLIENT && !C is not official yet, and when it will become official it will have a ChangeLog entry with a scope much broader than just this :)

[mpg]

• development PR not required because, if I'm not wrong, the MD module is internal in development, so the user is not able to make direct usage of it.

The current plan is for MD to remain public in 4.0, so I think we want to forward-port this to development. However there might be other changes planned (or already done) in development that would make this moot, I'm not sure. Cc @gilles-peskine-arm

[mpg]

The ABI-API break is expected because struct mbedtls_md_context_t will change its size depending on PSA_WANT_ instead of MBEDTLS_PSA_ACCEL_ symbols.

Aw, I'm afraid this is a blocker. We promise not to change the ABI in LTS branches (which 3.6 now is) unless we can't find another way to fix a security issue. So, changing the size of struct mbedtls_md_context_t in the default configuration is not something we can do in 3.6.

Would there be a way to achieve what you're after while keeping the structure unchanged in the default config, and only changing it in a few specific configs?

[mpg]

#9562 (comment)

[valeriosetti]

The current plan is for MD to remain public in 4.0, so I think we want to forward-port this to development.

Oh, I see. I based my previous comment on the fact that md.h header is now in tf-psa-crypto/drivers/builtin/include/mbedtls/md.h which looks like a quite "hidden" place not meant to be included by end user's code directly. However I surely missed something, so please apologize for the wrong assumption.

Would there be a way to achieve what you're after while keeping the structure unchanged in the default config, and only changing it in a few specific configs?

I think the easiest way will be to enable PSA dispatching based on PSA_WANTs only in the usual CRYPTO_CLIENT && !CRYPTO_C configuration. This is still relevant for Mbed TLS users like Zephyr, but it does not affect the default configuration. I will try to rework the PR in this direction.

[gilles-peskine-arm]

The current plan is for MD to remain public in 4.0, so I think we want to forward-port this to development.

Oh, I see. I based my previous comment on the fact that md.h header is now in tf-psa-crypto/drivers/builtin/include/mbedtls/md.h which looks like a quite "hidden" place not meant to be included by end user's code directly. However I surely missed something, so please apologize for the wrong assumption.

Currently all of the legacy crypto headers have moved as part of the work to split the repositories. We'll move some of them again as part of the work to evolve the API. md.h will remain public (but without HMAC functionality). Most other crypto headers will become private or unstable.

Sorry about the lack of clarity. We're still working on clarifying what's going to happen and making a plan for it to happen in time.

[valeriosetti]

Would there be a way to achieve what you're after while keeping the structure unchanged in the default config, and only changing it in a few specific configs?

I think the easiest way will be to enable PSA dispatching based on PSA_WANTs only in the usual CRYPTO_CLIENT && !CRYPTO_C configuration. This is still relevant for Mbed TLS users like Zephyr, but it does not affect the default configuration. I will try to rework the PR in this direction.

Thanks to this change the ABI-API failure disappeared and the CI is fully green now :)

The current plan is for MD to remain public in 4.0, so I think we want to forward-port this to development.

Oh, I see. I based my previous comment on the fact that md.h header is now in tf-psa-crypto/drivers/builtin/include/mbedtls/md.h which looks like a quite "hidden" place not meant to be included by end user's code directly. However I surely missed something, so please apologize for the wrong assumption.

Currently all of the legacy crypto headers have moved as part of the work to split the repositories. We'll move some of them again as part of the work to evolve the API. #8450 (but without HMAC functionality). #8663.

Thanks a lot for the update! So I think that the forward port of this fix will need to wait until MD design is stabilized/planned on development.

[mpg]

LGTM, thanks!

[gilles-peskine-arm]

Thanks for updating the documentation! Looks good to me now.

[mpg]

LGTM, thanks!

[mpg]

@valeriosetti can you update the submodule pointer now that Mbed-TLS/mbedtls-framework#140 has been merged?

[gilles-peskine-arm]

LGTM after framework update

[gilles-peskine-arm]

Can you please make a PR to development? Sure, the md interface will change, but that doesn't affect the changes here.

[valeriosetti]

Can you please make a PR to development? Sure, the md interface will change, but that doesn't affect the changes here.

I was about to start the forward porting few days ago, but then went checking the current status of development. There MD module is internal in TF-PSA-Crypto repo so in theory end users should not include/use it directly. As far as I saw TLS code only imports md.h to have new types definition and few #defines.
In short, I didn't saw any benefit in forward porting this PR so I stopped. Do you think it's still worth it? If so I can start the forward port anyway

[gilles-peskine-arm]

md.h will remain public in TF-PSA-Crypto 1.x, with a subset of functionality: just hash calculation, not HMAC or metadata. Basically the current MBEDTLS_MD_LIGHT.