Received-SPF: pass (google.com: domain of linux-kernel+bounces-66443-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <a9e263becefe001ec5de4abf79bbdb49a2c35033.camel@huaweicloud.com>
Subject: Re: [PATCH v1 5/5] sbm: SandBox Mode documentation
From: Roberto Sassu <roberto.sassu@huaweicloud.com>
To: Kent Overstreet <kent.overstreet@linux.dev>, Petr
	=?UTF-8?Q?Tesa=C5=99=C3=ADk?=
	 <petr@tesarici.cz>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Andrew Morton
 <akpm@linux-foundation.org>, Petr Tesarik <petrtesarik@huaweicloud.com>, 
 Jonathan Corbet <corbet@lwn.net>, David Kaplan <david.kaplan@amd.com>,
 Larry Dewey <larry.dewey@amd.com>, Elena Reshetova
 <elena.reshetova@intel.com>, Carlos Bilbao <carlos.bilbao@amd.com>, "Masami
 Hiramatsu (Google)" <mhiramat@kernel.org>, Randy Dunlap
 <rdunlap@infradead.org>, Petr Mladek <pmladek@suse.com>, "Paul E. McKenney"
 <paulmck@kernel.org>, Eric DeVolder <eric.devolder@oracle.com>, Marc
 =?ISO-8859-1?Q?Aur=E8le?= La France <tsi@tuyoix.net>, "Gustavo A. R. Silva"
 <gustavoars@kernel.org>, Nhat Pham <nphamcs@gmail.com>, "Christian Brauner
 (Microsoft)" <brauner@kernel.org>,  Douglas Anderson
 <dianders@chromium.org>, Luis Chamberlain <mcgrof@kernel.org>, Guenter
 Roeck <groeck@chromium.org>,  Mike Christie <michael.christie@oracle.com>,
 Maninder Singh <maninder1.s@samsung.com>, "open list:DOCUMENTATION"
 <linux-doc@vger.kernel.org>, open list <linux-kernel@vger.kernel.org>, Petr
 Tesarik <petr.tesarik1@huawei-partners.com>,
 linux-security-module@vger.kernel.org,  keyrings@vger.kernel.org
Date: Thu, 15 Feb 2024 09:52:43 +0100
In-Reply-To: <xg7iz7syomv3oobjktgn76fyxms4vfs66jul56ub36prwnncxm@hsjhc5m72ipq>
References: <20240214113035.2117-1-petrtesarik@huaweicloud.com>
	 <20240214113035.2117-6-petrtesarik@huaweicloud.com>
	 <20240214053053.982b48d993ae99dad1d59020@linux-foundation.org>
	 <2024021425-audition-expand-2901@gregkh>
	 <20240214155524.719ffb15@meshulam.tesarici.cz>
	 <2024021415-jokester-cackle-2923@gregkh>
	 <20240214173112.138e0e29@meshulam.tesarici.cz>
	 <g3llwlzlhatvz2a23cntx7lscqarepq4uyaq6wne6my7ddo3mk@6b64pjcnykah>
	 <20240214210937.3a19945f@meshulam.tesarici.cz>
	 <xg7iz7syomv3oobjktgn76fyxms4vfs66jul56ub36prwnncxm@hsjhc5m72ipq>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4-0ubuntu2 
Precedence: bulk
MIME-Version: 1.0

On Wed, 2024-02-14 at 15:19 -0500, Kent Overstreet wrote:
> On Wed, Feb 14, 2024 at 09:09:37PM +0100, Petr Tesa=C5=99=C3=ADk wrote:
> > On Wed, 14 Feb 2024 13:54:54 -0500
> > Kent Overstreet <kent.overstreet@linux.dev> wrote:
> >=20
> > > On Wed, Feb 14, 2024 at 05:31:12PM +0100, Petr Tesa=C5=99=C3=ADk wrot=
e:
> > > > On Wed, 14 Feb 2024 16:11:05 +0100
> > > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > >  =20
> > > > > On Wed, Feb 14, 2024 at 03:55:24PM +0100, Petr Tesa=C5=99=C3=ADk =
wrote: =20
> > > > > > OK, so why didn't I send the whole thing?
> > > > > >=20
> > > > > > 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 t=
o get
> > > > > > feedback from guys like you, to know if the whole idea would be=
 even
> > > > > > considered, aka "Fail Fast".   =20
> > > > >=20
> > > > > We can't honestly consider this portion without seeing how it wou=
ld
> > > > > work, as we don't even see a working implementation that uses it =
to
> > > > > verify it at all.
> > > > >=20
> > > > > The joy of adding new frameworks is that you need a user before a=
nyone
> > > > > can spend the time to review it, sorry. =20
> > > >=20
> > > > 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 ga=
ps),
> > > > or do you need clean and nice kernel code? =20
> > >=20
> > > Given that code is going to need a rewrite to make use of this anyway=
s -
> > > why not just do the rewrite in Rust?
> >=20
> > Thank you for this question! I concur that rewriting the whole kernel
> > in Rust would be a better option. I see two differences:
> >=20
> > 1. amount of work
> > 2. regressions
> >=20
> > 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=E2=80=99ve been fixed. If you write code from scratch, you los=
e much
> > of the accumulated knowledge.
>=20
> But it's work that already has some growing momentum behind it,
> especially in the area you cited - decompression algorithms.
>=20
> > 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.
>=20
> You see this as a tool for general purpose code...?
>=20
> Typical kernel code tends to be quite pointer heavy.
>=20
> > > Then you get memory safety, which seems to be what you're trying to
> > > achieve here.
> > >=20
> > > Or, you say this is for when performance isn't critical - why not a u=
ser
> > > mode helper?
> >=20
> > 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.
>=20
> [citation needed]
>=20
> Running code in the kernel does not make it more secure from attack, and
> that's a pretty strange idea. One of the central jobs of the kernel is
> to provide isolation between different users.

+ linux-security-module, keyrings

It is not exactly about being more secure, but more privileged.

I had a question in the past:

https://lore.kernel.org/linux-integrity/eb31920bd00e2c921b0aa6ebed8745cb013=
0b0e1.camel@huaweicloud.com/


I basically need to parse PGP keys, to verify RPM package headers,
extract the file digests from them, and use those digests as reference
values for the kernel to decide whether or not files can be accessed
depending on their integrity.

It is very important that, in a locked-down system, even root is
subject to integrity checks. So, the kernel has higher privileges than
root.

Can the kernel be trusted to provide strong enough process isolation,
even against root, in a way that it can offload a workload to a user
space process (PGP parsing), and yet maintain its privilege level
(which would drop to root, if isolation cannot be guaranteed)?

So, since we got no as an answer, we thought about something in the
middle, we still run the code in the kernel, to keep the higher
privilege, but at the same time we mitigate the risk of kernel memory
corruption.

Roberto