Add a section for transparent drivers
No strategy yet, just state some basic requirements. Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This commit is contained in:
parent
f0e2853d46
commit
24cebf6671
1 changed files with 18 additions and 0 deletions
|
@ -113,3 +113,21 @@ We should have at least one driver that covers the whole interface:
|
|||
* Run the full driver validation test suite (which does not yet exist).
|
||||
|
||||
A PKCS#11 driver would be a good candidate. It would be useful as part of our product offering.
|
||||
|
||||
## Transparent driver interface testing
|
||||
|
||||
The [unified driver interface](../../proposed/psa-driver-interface.md) defines interfaces for accelerators.
|
||||
|
||||
### Test requirements
|
||||
|
||||
#### Requirements for transparent driver testing
|
||||
|
||||
Every cryptographic mechanism for which a transparent driver interface exists (key creation, cryptographic operations, …) must be exercised in at least one build. The test must verify that the driver code is called.
|
||||
|
||||
#### Requirements for fallback
|
||||
|
||||
The driver interface includes a fallback mechanism so that a driver can reject a request at runtime and let another driver handle the request. For each entry point, there must be at least three test runs with two or more drivers available with driver A configured to fall back to driver B, with one run where A returns `PSA_SUCCESS`, one where A returns `PSA_ERROR_NOT_SUPPORTED` and B is invoked, and one where A returns a different error and B is not invoked.
|
||||
|
||||
## Entropy and randomness interface testing
|
||||
|
||||
TODO
|
||||
|
|
Loading…
Reference in a new issue