linux-kernel - Re: [PATCH v1 5/5] sbm: SandBox Mode documentation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 14 Feb 2024 15:01:25 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: 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>,
	Kent Overstreet <kent.overstreet@...ux.dev>,
	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@...arici.cz,
	Petr Tesarik <petr.tesarik1@...wei-partners.com>
Subject: Re: [PATCH v1 5/5] sbm: SandBox Mode documentation

On Wed, Feb 14, 2024 at 05:30:53AM -0800, Andrew Morton wrote:
> On Wed, 14 Feb 2024 12:30:35 +0100 Petr Tesarik <petrtesarik@...weicloud.com> wrote:
> 
> > +Although data structures are not serialized and deserialized between kernel
> > +mode and sandbox mode, all directly and indirectly referenced data structures
> > +must be explicitly mapped into the sandbox, which requires some manual effort.
> 
> Maybe I'm missing something here, but...
> 
> The requirement that the sandboxed function only ever touch two linear
> blocks of memory (yes?) seems a tremendous limitation.  I mean, how can
> the sandboxed function call kmalloc()?  How can it call any useful
> kernel functions?  They'll all touch memory which lies outside the
> sandbox areas?
> 
> Perhaps a simple but real-world example would help clarify.

I agree, this looks like an "interesting" framework, but we don't add
code to the kernel without a real, in-kernel user for it.

Without such a thing, we can't even consider it for inclusion as we
don't know how it will actually work and how any subsystem would use it.

Petr, do you have an user for this today?

thanks,

greg k-h