Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mbedtls: use static key slot buffers in the PSA Crypto core #80368
mbedtls: use static key slot buffers in the PSA Crypto core #80368
Changes from all commits
1918683
c06a692
7dc3c18
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Won't
MBEDTLS_*
symbols also affect this? e.g. if I enable some key type via that and notPSA_WANT
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be true only if you build Mbed TLS with MBEDTLS_PSA_CRYPTO_C enabled but not MBEDTLS_PSA_CRYPTO_CONFIG so that PSA_WANTs are derived/guessed from legacy symbols, but this is not something we do in Zephyr
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So with how we do it in Zephyr, PSA_WANTs are not enabled by Mbed TLS symbols? It's only the other way around?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since PSA crypto is the defacto crypto API in zephyr, the PSA_WANT_ALG_XXX etc. is the appropriate way forward.
Legacy CONFIGS converted to PSA crypto has code-size and ram size side-effects, and it also makes it difficult to optimize
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What was the rationale for choosing 16? I'm wondering if we should make that default still a bit smaller.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@frkv suggested this so I'll leave the answer to him
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that it will be very difficult to dictate a "one number that fits all" here, unless we start using
depends on
rules taking into consider the possibility of multiple supported protocols, number of consecutive links etc...The default number of keys allocated in the current version of Mbed TLS is 32, and we have already reduced this number to half of that.
Please see:
https://github.com/Mbed-TLS/mbedtls/blob/107ea89daaefb9867ea9121002fbbdf926780e98/include/mbedtls/mbedtls_config.h#L4070
https://github.com/Mbed-TLS/mbedtls/blob/107ea89daaefb9867ea9121002fbbdf926780e98/include/psa/crypto_extra.h#L32
It is hard to answer definitely how many keys are needed at the same time, but if you set the default too low it may be a cause of runtime-failures that new users might waste precious time on...
If the end-product doesn't rely on that many keys, then it is adjustable down at will, when doing optimization...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was suggesting to set it down to ~12 because from my quick calculation (based on Valerio's showcase data in the PR description) it seemed that a number bigger than that would increase the RAM usage. Although in practice it actually depends on the key types enabled. So yeah, it's not that easy of a choice.
I was just trying to avoid increasing the footprint (because that goes against the original goal).
Maybe we could at least make sure to properly document this as a possible optimization path (so that users come across it easily).