From 7bc1bb65e9dc89f80c251d3b417f6a9710323869 Mon Sep 17 00:00:00 2001 From: Gilles Peskine Date: Fri, 13 Oct 2023 20:05:25 +0200 Subject: [PATCH] Short explanations of what is expected in the design sections Signed-off-by: Gilles Peskine --- docs/architecture/psa-shared-memory.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/architecture/psa-shared-memory.md b/docs/architecture/psa-shared-memory.md index da6da2212f..440281705f 100644 --- a/docs/architecture/psa-shared-memory.md +++ b/docs/architecture/psa-shared-memory.md @@ -236,18 +236,20 @@ Copy what needs copying. This seems straightforward. ### Validation of copying -TODO +TODO: how to we validate that we didn't forget to copy? Proposed general idea: have tests where the test code calling API functions allocates memory in a certain pool, and code in the library allocates memory in a different pool. Test drivers check that needs-copying arguments are within the library pool, not within the test pool. +Note: we could also validate by unmapping or poisoning the memory containing the API function arguments while the driver is working. But how would we validate that we have poison/unmap calls in the right places? + ### Shared memory protection requirements TODO: write document and reference it here. ### Validation of protection for built-in drivers -TODO +TODO: when there is a requirement on drivers, how to we validate that our built-in implementation meets these requirements? (This may be through testing, review, static analysis or any other means or a combination.) ## Analysis of argument protection in built-in drivers -TODO +TODO: analyze the built-in implementations of mechanisms for which there is a requirement on drivers. By code inspection, how satisfied are we that they meet the requirement?