From 2859267a27e23f1eb551ba01ba7c76c74c70489c Mon Sep 17 00:00:00 2001 From: Gilles Peskine Date: Fri, 13 Oct 2023 20:01:36 +0200 Subject: [PATCH] Clarify terminology: built-in driver Signed-off-by: Gilles Peskine --- docs/architecture/psa-shared-memory.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/architecture/psa-shared-memory.md b/docs/architecture/psa-shared-memory.md index 5d3273a1a7..57341b09ef 100644 --- a/docs/architecture/psa-shared-memory.md +++ b/docs/architecture/psa-shared-memory.md @@ -119,7 +119,7 @@ A call to a crypto service to perform a crypto operation involves the following 1. The remote procedure call framework provided by the operating system. 2. The code of the crypto service. 3. The code of the PSA Crypto dispatch layer (also known as the core), which is provided by Mbed TLS. -4. The implementation of the cryptographic mechanism, which may be provided by Mbed TLS or by a third-party driver. +4. The driver implementing the cryptographic mechanism, which may be provided by Mbed TLS (built-in driver) or by a third-party driver. The [PSA Crypto API specification](https://arm-software.github.io/psa-api/crypto/1.1/overview/conventions.html#stability-of-parameters) puts the responsibility for protection on the implementation of the PSA Crypto API, i.e. (3) or (4). @@ -223,10 +223,10 @@ Proposed general idea: have tests where the test code calling API functions allo TODO: write document and reference it here. -### Validation of protection for built-in mechanisms +### Validation of protection for built-in drivers TODO -## Analysis of argument protection in built-in mechanisms +## Analysis of argument protection in built-in drivers TODO