Received-SPF: pass (google.com: domain of linux-kernel+bounces-65884-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Wed, 14 Feb 2024 20:35:29 +0100
From: Petr =?UTF-8?B?VGVzYcWZw61r?= <petr@tesarici.cz>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Cc: "Xu, Pengfei" <pengfei.xu@intel.com>, "tglx@linutronix.de"
 <tglx@linutronix.de>, "luto@kernel.org" <luto@kernel.org>,
 "kirill.shutemov@linux.intel.com" <kirill.shutemov@linux.intel.com>,
 "brgerst@gmail.com" <brgerst@gmail.com>, "jgg@ziepe.ca" <jgg@ziepe.ca>,
 "corbet@lwn.net" <corbet@lwn.net>, "Li, Xin3" <xin3.li@intel.com>,
 "roberto.sassu@huaweicloud.com" <roberto.sassu@huaweicloud.com>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 "petr.tesarik1@huawei-partners.com" <petr.tesarik1@huawei-partners.com>,
 "dwmw@amazon.co.uk" <dwmw@amazon.co.uk>, "x86@kernel.org" <x86@kernel.org>,
 "bp@alien8.de" <bp@alien8.de>, "peterz@infradead.org"
 <peterz@infradead.org>, "rppt@kernel.org" <rppt@kernel.org>,
 "arnd@arndb.de" <arnd@arndb.de>, "mhiramat@kernel.org"
 <mhiramat@kernel.org>, "oleg@redhat.com" <oleg@redhat.com>,
 "keescook@chromium.org" <keescook@chromium.org>, "Huang, Kai"
 <kai.huang@intel.com>, "jacob.jun.pan@linux.intel.com"
 <jacob.jun.pan@linux.intel.com>, "zegao2021@gmail.com"
 <zegao2021@gmail.com>, "hpa@zytor.com" <hpa@zytor.com>, "mingo@redhat.com"
 <mingo@redhat.com>, "jpoimboe@kernel.org" <jpoimboe@kernel.org>, "Rodel,
 Jorg" <jroedel@suse.de>, "Zhang, Tina" <tina.zhang@intel.com>, "Hansen,
 Dave" <dave.hansen@intel.com>, "linux-doc@vger.kernel.org"
 <linux-doc@vger.kernel.org>, "akpm@linux-foundation.org"
 <akpm@linux-foundation.org>, "dave.hansen@linux.intel.com"
 <dave.hansen@linux.intel.com>, "petrtesarik@huaweicloud.com"
 <petrtesarik@huaweicloud.com>
Subject: Re: [PATCH v1 0/8] x86_64 SandBox Mode arch hooks
Message-ID: <20240214203529.68eccc68@meshulam.tesarici.cz>
In-Reply-To: <78fe4fdefa4f427b3fb1b6968d8799035c0c4124.camel@intel.com>
References: <20240214113516.2307-1-petrtesarik@huaweicloud.com>
	<c424618c-d6c6-430a-8975-8851a617204e@intel.com>
	<34B19756-91D3-4DA1-BE76-BD3122C16E95@zytor.com>
	<20240214174143.74a4f10c@meshulam.tesarici.cz>
	<a27c9c32e410fc3582f3593f209cc1cf3b287042.camel@intel.com>
	<20240214193241.7447a082@meshulam.tesarici.cz>
	<78fe4fdefa4f427b3fb1b6968d8799035c0c4124.camel@intel.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, 14 Feb 2024 19:19:27 +0000
"Edgecombe, Rick P" <rick.p.edgecombe@intel.com> wrote:

> On Wed, 2024-02-14 at 19:32 +0100, Petr Tesa=C5=99=C3=ADk wrote:
> > > What use case needs to have the sandbox both protected from the
> > > kernel
> > > (trusted operations) and non-privileged (the kernel protected from
> > > it
> > > via CPL3)? It seems like opposite things. =20
> >=20
> > I think I have mentioned one: parsing keys for the trusted keyring.
> > The
> > parser is complex enough to be potentially buggy, but the security
> > folks have already dismissed the idea to run it as a user mode
> > helper. =20
>=20
> Ah, I didn't realize the kernel needed to be protected from the key
> parsing part because you called it out as a trusted operation. So on
> the protect-the-kernel-side it's similar to the microkernel security
> reasoning.
>=20
> Did I get the other part wrong - that you want to protect the sandbox
> from the rest of kernel as well?

Protecting the sandbox from the rest of the kernel is out of scope.
However, different sandboxes should be protected from each other.

Petr T