On 2/14/2024 3:35 AM, Petr Tesarik wrote:
From: Petr Tesarik <petr.tesarik1@xxxxxxxxxxxxxxxxxxx>
Add a section about the x86-64 implementation.
Signed-off-by: Petr Tesarik <petr.tesarik1@xxxxxxxxxxxxxxxxxxx>
---
Documentation/security/sandbox-mode.rst | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/Documentation/security/sandbox-mode.rst b/Documentation/security/sandbox-mode.rst
index 4405b8858c4a..84816b6b68de 100644
--- a/Documentation/security/sandbox-mode.rst
+++ b/Documentation/security/sandbox-mode.rst
where is this file?
I assumed it's newly added, but your patch doesn't say so.
@@ -111,6 +111,31 @@ These hooks must be implemented to select HAVE_ARCH_SBM.
:identifiers: arch_sbm_init arch_sbm_destroy arch_sbm_exec
arch_sbm_map_readonly arch_sbm_map_writable
+X86_64 Implementation
+=====================
+
+The x86_64 implementation provides strong isolation and recovery from CPU
+exceptions.
+
+Sandbox mode runs in protection ring 3 (same as user mode). This means that:
+
+* sandbox code cannot execute privileged CPU instructions,
+* memory accesses are treated as user accesses.
+
+The thread stack is readable in sandbox mode, because an on-stack data
+structure is used by call helpers and thunks to pass target function
+arguments. However, it is not writable, and sandbox code runs on its own
+stack. The thread stack is not used by interrupt handlers either. Non-IST
+interrupt handlers run on a separate sandbox exception stack.
+
+The interrupt entry path modifies the saved pt_regs to make it appear as
+coming from kernel mode. The CR3 register is then switched to kernel mode.
+The interrupt exit path is modified to restore actual pt_regs and switch the
+CR3 register back to its sandbox mode value, overriding CR3 changes for page
+table isolation.
+
+Support for paravirtualized kernels is not (yet) provided.
+
Current Limitations
===================
