From 806055edbf5b953aa9b5d5cec5e161c885fbb2f2 Mon Sep 17 00:00:00 2001 From: David Horstmann Date: Mon, 23 Oct 2023 19:53:30 +0100 Subject: [PATCH] Refactor note on preferred poison-test approach Signed-off-by: David Horstmann --- docs/architecture/psa-shared-memory.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/architecture/psa-shared-memory.md b/docs/architecture/psa-shared-memory.md index c3894a31f5..9929573fc0 100644 --- a/docs/architecture/psa-shared-memory.md +++ b/docs/architecture/psa-shared-memory.md @@ -501,10 +501,12 @@ This should either poison or unpoison the given buffer based on the value of `sh * When `should_poison == 1`, this is equivalent to calling `VALGRIND_MAKE_MEM_NOACCESS(buffer, length)` or `ASAN_POISON_MEMORY_REGION(buffer, length)`. * When `should_poison == 0`, this is equivalent to calling `VALGRIND_MAKE_MEM_DEFINED(buffer, length)` or `ASAN_UNPOISON_MEMORY_REGION(buffer, length)`. -We may choose one of two approaches. As discussed in [the design exploration](#validation-with-existing-tests), the first is preferred: +We may choose one of two approaches: * Use transparent allocation-based memory poisoning. * Use memory poisoning functions and a new testsuite. +As discussed in [the design exploration](#validation-with-existing-tests), the transparent approach is preferred. + We will specify the particularities of each approach's implementation below. #### Transparent allocation-based memory poisoning