-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Backport 3.6: prepare for dynamic key store #9403
Backport 3.6: prepare for dynamic key store #9403
Conversation
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>
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>
Convert `#if !... A #else B #endif` to `#if ... B #else A`. No semantic change. 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 Mbed-TLS#9253. 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>
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>
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>
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>
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>
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>
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>
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>
d50b01f
to
d66dc64
Compare
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 only found one possible typo to fix.
Other than this the PR is OK for me.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
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.
Thanks for the fix. LGTM
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.
Looks good apart from these things, thanks!
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Replace the hard-coded 1 by the proper constant now that the proper constant exists. Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
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.
One typo, LGTM otherwise
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
d226925
to
aaa9672
Compare
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.
LGTM, thanks!
Several robustness improvements that I made to prepare for #9240. I split them out to make the review easier, so #9240 will focus on the new feature.
This is work towards #9216, which will be completed in #9240.
PR checklist