From 24cebf6671f58cc0a67578e1d12eba8991194c3d Mon Sep 17 00:00:00 2001 From: Gilles Peskine Date: Mon, 30 Nov 2020 17:51:53 +0100 Subject: [PATCH] Add a section for transparent drivers No strategy yet, just state some basic requirements. Signed-off-by: Gilles Peskine --- .../testing/driver-interface-test-strategy.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/docs/architecture/testing/driver-interface-test-strategy.md b/docs/architecture/testing/driver-interface-test-strategy.md index 57b1a237f..086fc1adb 100644 --- a/docs/architecture/testing/driver-interface-test-strategy.md +++ b/docs/architecture/testing/driver-interface-test-strategy.md @@ -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