[v1,7/8] sbm: documentation of the x86-64 SandBox Mode implementation

Message ID 20240214113516.2307-8-petrtesarik@huaweicloud.com
State New
Headers
Series x86_64 SandBox Mode arch hooks |

Commit Message

Petr Tesarik Feb. 14, 2024, 11:35 a.m. UTC
  From: Petr Tesarik <petr.tesarik1@huawei-partners.com>

Add a section about the x86-64 implementation.

Signed-off-by: Petr Tesarik <petr.tesarik1@huawei-partners.com>
---
 Documentation/security/sandbox-mode.rst | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)
  

Comments

Xin Li (Intel) Feb. 14, 2024, 6:37 p.m. UTC | #1
On 2/14/2024 3:35 AM, Petr Tesarik wrote:
> From: Petr Tesarik <petr.tesarik1@huawei-partners.com>
> 
> Add a section about the x86-64 implementation.
> 
> Signed-off-by: Petr Tesarik <petr.tesarik1@huawei-partners.com>
> ---
>   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
>   ===================
>
  
Petr Tesařík Feb. 14, 2024, 7:16 p.m. UTC | #2
On Wed, 14 Feb 2024 10:37:19 -0800
Xin Li <xin@zytor.com> wrote:

> On 2/14/2024 3:35 AM, Petr Tesarik wrote:
> > From: Petr Tesarik <petr.tesarik1@huawei-partners.com>
> > 
> > Add a section about the x86-64 implementation.
> > 
> > Signed-off-by: Petr Tesarik <petr.tesarik1@huawei-partners.com>
> > ---
> >   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.

Ah, right, for people who are not on the Cc list of my arch-independent
series, this series is entirely out of context. FWIW the first part is here:

https://lore.kernel.org/lkml/20240214113035.2117-1-petrtesarik@huaweicloud.com/

I wonder, would it be better to resend it with a more complete list of
recipients?

Petr T
  

Patch

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
@@ -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
 ===================