Hi Beat,

This is still an open point in the design.

It's clear that some back-and-forth is needed. An accelerator needing a source of randomness is a good example. In some cases, it's possible to have the core call a deterministic function in the driver, for example accelerated RSA-PSS can often be broken down into the RSA exponentiation (accelerated) and PSS padding (unaccelerated except maybe for the hash calculations, done by the core). This kind of scenario calls for additional entry points in the driver, which has the advantage of not requiring any control inversion. These additional entry points are evoked under “substitution points” in the specification draft.

However, other cases cannot be done this way, for example if a driver needs a random generator to perform blinding. Other examples include an opaque driver using a local cipher to encrypt communication with a secure element over an insecure bus, or a driver loading an auxiliary firmware image and verifying its signature. These cases are varied enough that I think it must be possible for drivers to call any API function. But as you note this may cause reentrancy problems, so there should be some limitations.

It's not clear to me at this stage what the limitations should be. For example, what rules would facilitate static bounds on stack usage? Can the rules be enforced cheaply at runtime, and are violations likely to be detected by unit tests? Can the rules realistically be validated by static analysis?

The exact manner in which drivers might call core functions is also open. Are there additional auxiliary functions that the core should expose (for example, might a driver prefer to have the core expose rsa_pss_pad())? The functions that the driver sees are not necessarily the same that the functions that applications see (at the very least, they're different on platforms where applications run in their own memory space and PSA API calls are remote procedure calls, whereas drivers live in the crypto service's memory space). So they can't be guaranteed to have the same symbol name. Types like psa_key_id_t and psa_key_attributes_t may be different in applications and in drivers as well.

I expect it's going to take a while to converge on all of these open questions. As the use cases are diverse, feedback is very welcome.