Received-SPF: pass (google.com: domain of linux-kernel+bounces-65681-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 09:29:06 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
To: =?UTF-8?Q?Petr_Tesa=C5=99=C3=ADk?= <petr@tesarici.cz>
CC: Dave Hansen <dave.hansen@intel.com>,
        Petr Tesarik <petrtesarik@huaweicloud.com>,
        Jonathan Corbet <corbet@lwn.net>, Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@kernel.org>,
        Andy Lutomirski <luto@kernel.org>, Oleg Nesterov <oleg@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>, Xin Li <xin3.li@intel.com>,
        Arnd Bergmann <arnd@arndb.de>,
        Andrew Morton <akpm@linux-foundation.org>,
        Rick Edgecombe <rick.p.edgecombe@intel.com>,
        Kees Cook <keescook@chromium.org>,
        "Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
        Pengfei Xu <pengfei.xu@intel.com>,
        Josh Poimboeuf <jpoimboe@kernel.org>, Ze Gao <zegao2021@gmail.com>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Kai Huang <kai.huang@intel.com>, David Woodhouse <dwmw@amazon.co.uk>,
        Brian Gerst <brgerst@gmail.com>, Jason Gunthorpe <jgg@ziepe.ca>,
        Joerg Roedel <jroedel@suse.de>,
        "Mike Rapoport (IBM)" <rppt@kernel.org>,
        Tina Zhang <tina.zhang@intel.com>,
        Jacob Pan <jacob.jun.pan@linux.intel.com>,
        "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>,
        Roberto Sassu <roberto.sassu@huaweicloud.com>,
        Petr Tesarik <petr.tesarik1@huawei-partners.com>
Subject: Re: [PATCH v1 0/8] x86_64 SandBox Mode arch hooks
User-Agent: K-9 Mail for Android
In-Reply-To: <20240214174143.74a4f10c@meshulam.tesarici.cz>
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>
Message-ID: <9EF956AB-DF48-4DAA-AB42-0FBC513ECA22@zytor.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

On February 14, 2024 8:41:43 AM PST, "Petr Tesa=C5=99=C3=ADk" <petr@tesaric=
i=2Ecz> wrote:
>On Wed, 14 Feb 2024 07:28:35 -0800
>"H=2E Peter Anvin" <hpa@zytor=2Ecom> wrote:
>
>> On February 14, 2024 6:52:53 AM PST, Dave Hansen <dave=2Ehansen@intel=
=2Ecom> wrote:
>> >On 2/14/24 03:35, Petr Tesarik wrote: =20
>> >> This patch series implements x86_64 arch hooks for the generic SandB=
ox
>> >> Mode infrastructure=2E =20
>> >
>> >I think I'm missing a bit of context here=2E  What does one _do_ with
>> >SandBox Mode?  Why is it useful? =20
>>=20
>> Seriously=2E On the surface it looks like a really bad idea =E2=80=93 b=
asically an ad hoc, *more* privileged version of user shave=2E
>
>Hi hpa,
>
>I agree that it kind of tries to do "user mode without user mode"=2E
>There are some differences from actual user mode:
>
>First, from a process management POV, sandbox mode appears to be
>running in kernel mode=2E So, there is no way to use ptrace(2), send
>malicious signals or otherwise interact with the sandbox=2E In fact,
>the process can have three independent contexts: user mode, kernel mode
>and sandbox mode=2E
>
>Second, a sandbox can run unmodified kernel code and interact directly
>with other parts of the kernel=2E It's not really possible with this
>initial patch series, but the plan is that sandbox mode can share locks
>with the kernel=2E
>
>Third, sandbox code can be trusted for operations like parsing keys for
>the trusted keychain if the kernel is locked down, i=2Ee=2E when even a
>process with UID 0 is not on the same trust level as kernel mode=2E
>
>HTH
>Petr T
>

This, to me, seems like "all the downsides of a microkernel without the up=
sides=2E" Furthermore, it breaks security-hardening features like LASS and =
(to a lesser degree) SMAP=2E Not to mention dropping global pages?

All in all, I cannot see this as anything other than an enormous step in t=
he wrong direction, and it isn't even in the sense of "it is harmless if no=
one uses it" =E2=80=93 you are introducing architectural changes that are m=
ost definitely *very* harmful both to maintainers and users=2E

To me, this feels like paravirtualization all over again=2E 20 years later=
 we still have not been able to undo all the damage that did=2E