Message-ID: <20240215074257.10e00a53@meshulam.tesarici.cz>
Date: Thu, 15 Feb 2024 07:42:57 +0100
From: Petr Tesařík <petr@...arici.cz>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Andrew Morton
 <akpm@...ux-foundation.org>, Petr Tesarik <petrtesarik@...weicloud.com>,
 Jonathan Corbet <corbet@....net>, David Kaplan <david.kaplan@....com>,
 Larry Dewey <larry.dewey@....com>, Elena Reshetova
 <elena.reshetova@...el.com>, Carlos Bilbao <carlos.bilbao@....com>, "Masami
 Hiramatsu (Google)" <mhiramat@...nel.org>, Randy Dunlap
 <rdunlap@...radead.org>, Petr Mladek <pmladek@...e.com>, "Paul E. McKenney"
 <paulmck@...nel.org>, Eric DeVolder <eric.devolder@...cle.com>, Marc
 Aurèle La France <tsi@...oix.net>, "Gustavo A. R. Silva"
 <gustavoars@...nel.org>, Nhat Pham <nphamcs@...il.com>, "Christian Brauner
 (Microsoft)" <brauner@...nel.org>, Douglas Anderson
 <dianders@...omium.org>, Luis Chamberlain <mcgrof@...nel.org>, Guenter
 Roeck <groeck@...omium.org>, Mike Christie <michael.christie@...cle.com>,
 Maninder Singh <maninder1.s@...sung.com>, "open list:DOCUMENTATION"
 <linux-doc@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>,
 Roberto Sassu <roberto.sassu@...weicloud.com>, Petr Tesarik
 <petr.tesarik1@...wei-partners.com>, Kees Cook <keescook@...omium.org>,
 Alexei Starovoitov <alexei.starovoitov@...il.com>
Subject: Re: [PATCH v1 5/5] sbm: SandBox Mode documentation

On Wed, 14 Feb 2024 15:19:04 -0500
Kent Overstreet <kent.overstreet@...ux.dev> wrote:

> On Wed, Feb 14, 2024 at 09:09:37PM +0100, Petr Tesařík wrote:
> > On Wed, 14 Feb 2024 13:54:54 -0500
> > Kent Overstreet <kent.overstreet@...ux.dev> wrote:
> >   
> > > On Wed, Feb 14, 2024 at 05:31:12PM +0100, Petr Tesařík wrote:  
> > > > On Wed, 14 Feb 2024 16:11:05 +0100
> > > > Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
> > > >     
> > > > > On Wed, Feb 14, 2024 at 03:55:24PM +0100, Petr Tesařík wrote:    
> > > > > > OK, so why didn't I send the whole thing?
> > > > > > 
> > > > > > Decomposition of the kernel requires many more changes, e.g. in linker
> > > > > > scripts. Some of them depend on this patch series. Before I go and
> > > > > > clean up my code into something that can be submitted, I want to get
> > > > > > feedback from guys like you, to know if the whole idea would be even
> > > > > > considered, aka "Fail Fast".      
> > > > > 
> > > > > We can't honestly consider this portion without seeing how it would
> > > > > work, as we don't even see a working implementation that uses it to
> > > > > verify it at all.
> > > > > 
> > > > > The joy of adding new frameworks is that you need a user before anyone
> > > > > can spend the time to review it, sorry.    
> > > > 
> > > > Thank your for a quick assessment. Will it be sufficient if I send some
> > > > code for illustration (with some quick&dirty hacks to bridge the gaps),
> > > > or do you need clean and nice kernel code?    
> > > 
> > > Given that code is going to need a rewrite to make use of this anyways -
> > > why not just do the rewrite in Rust?  
> > 
> > Thank you for this question! I concur that rewriting the whole kernel
> > in Rust would be a better option. I see two differences:
> > 
> > 1. amount of work
> > 2. regressions
> > 
> > Rewriting something in Rust means pretty much writing it from scratch.
> > Doing that necessarily introduces regressions. Old code has been used.
> > It has been tested. In many corner cases. Lots of bugs have been found,
> > and they’ve been fixed. If you write code from scratch, you lose much
> > of the accumulated knowledge.  
> 
> But it's work that already has some growing momentum behind it,
> especially in the area you cited - decompression algorithms.

Fair enough, this is indeed going for a better solution.

> > More importantly, sandbox mode can be viewed as a tool that enforces
> > decomposition of kernel code. This decomposition is the main benefit.
> > It requires understanding the dependencies among different parts of the
> > kernel (both code flow and data flow), and that will in turn promote
> > better design.  
> 
> You see this as a tool for general purpose code...?
> 
> Typical kernel code tends to be quite pointer heavy.

Yes. I believe this fact contributes to the difficulty of ensuring
memory safety in the kernel. With so much code potentially depnding on
any other kernel data structure, it does not help much that you protect
it as a whole. A finer-grained protection would make more sense.

> > > Then you get memory safety, which seems to be what you're trying to
> > > achieve here.
> > > 
> > > Or, you say this is for when performance isn't critical - why not a user
> > > mode helper?  
> > 
> > Processes in user mode are susceptible to all kinds of attacks you may
> > want to avoid. Sandbox mode can be used in situations where user mode
> > does not exist, e.g. to display a boot logo or to unpack initramfs.  
> 
> [citation needed]

I assume you mean citation for the kinds of attacks, not for the
unavailability of user space before initramfs is unpacked. ;-)

Here you go:

On Wed, 2023-03-22 at 15:27 -0700, Alexei Starovoitov wrote:
> On Wed, Mar 22, 2023 at 5:08 AM Roberto Sassu
[...]
> <roberto.sassu@...weicloud.com> wrote:
> > possible use case. The main goal is to move something that was running
> > in the kernel to user space, with the same isolation guarantees as if
> > the code was executed in the kernel.
> 
> They are not the same guarantees.
> UMD is exactly equivalent to root process running in user space.
> Meaning it can be killed, ptraced, priority inverted, etc

https://lore.kernel.org/lkml/CAADnVQJC0h7rtuntt0tqS5BbxWsmyWs3ZSbboZMmUKetMG2VhA@mail.gmail.com/

Petr T

Powered by blists - more mailing lists