yuzu-emu/mbedtls
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Add a section for transparent drivers

Browse source 
No strategy yet, just state some basic requirements.

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This commit is contained in:
Gilles Peskine 2020-11-30 17:51:53 +01:00
parent f0e2853d46
commit 24cebf6671
1 changed files with 18 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
docs/architecture/testing/driver-interface-test-strategy.md
View file

@ -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