Provide incremental by-subsystem initialization for the crypto library #202
Conversation
athoelke
added
enhancement
athoelke
force-pushed
the
crypto-partial-init
branch
from
314871a to
a4b7323
Compare
gilles-peskine-arm
left a comment
gilles-peskine-arm
left a comment
There was a problem hiding this comment.
This design was prototyped in Mbed-TLS/mbedtls#6636 and I consider that prototype to be sufficient validation for the API design.
The specification looks good to me except for a few places where some Mbed TLS specific history remains.
athoelke
force-pushed
the
crypto-partial-init
branch
from
a4b7323 to
5360369
Compare
|
Rebased and updated this PR |
There was a problem hiding this comment.
I've reviewed up to 5360369. Ok so far. Still to be addressed:
I think I've covered all except the need for some discussion of accelerators, secure elements, and built-in keys within the document. I plan to deal with that in a separate PR, unless you would prefer to keep it coupled with this one? |
|
Ah, I realise that this one still needs a change to the PR. |
|
Ok for a separate PR. But I don't think considerations around “drivers” and “built-in keys” should leak outside the specification of subsystem initialization for now. |
I think I could reword the text for the subsystem definitions to avoid talking about 'drivers' - which suggests a specific way of a portable implementation providing support for varied hardware. I just need to review the spec for a mention of 'secure element' and 'accelerator', and add/amend if necessary. |
|
I've added a couple more commits.
I think this addresses all of the outstanding comments. |
athoelke
force-pushed
the
crypto-partial-init
branch
from
74df62f to
0ad77a5
Compare
|
This is will not be in the next release of mbed TLS (4.0), and we prefer to only include new API when there is an implementation of the interface, |
athoelke
force-pushed
the
crypto-partial-init
branch
from
0fa957c to
9445f62
Compare
|
I've rebased this for possible inclusion into v1.5 |
athoelke
force-pushed
the
crypto-partial-init
branch
from
9445f62 to
8bc59ab
Compare
| See also :secref:`library-init`. | ||
|
|
||
| * If failure to initialize the library does not compromise the security of the function, the implementation must either provide the expected result for the function, or return :code:`PSA_ERROR_BAD_STATE` or other appropriate error. | ||
| .. typedef:: uint32_t psa_crypto_subsystem_t |
There was a problem hiding this comment.
In my prototype, I also had way to query the initialization state of subsystems. I implemented [int mbedtls_psa_crypto_is_subsystem_initialized(psa_crypto_subsystem_t) which returns a boolean result indicating whether the given subsystem mask is fully initialized. Another possibility would be a function that returns a subsystem mask indicating what is currently initialized. Would this be desirable as a standard function?
There was a problem hiding this comment.
Perhaps that makes sense. An is_initialized() boolean test matches the init() signature which is very tidy for code that wants to check - on the other hand just calling init(subset) on the same set of subsystems should always be quicker than if (!is_initialized(subset)) init(subset);.
So if we add an API, it might make more sense to be one that reports the set of initialized subsystems?
3 participants
See #16 for discussion of this API, which enables partial initialization of the library. This is useful in constrained contexts, for example during early boot, when not all library functionality is required to support the application use case.
Fixes #16