[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240214203331.240a6863@meshulam.tesarici.cz>
Date: Wed, 14 Feb 2024 20:33:31 +0100
From: Petr Tesařík <petr@...arici.cz>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Petr Tesarik <petrtesarik@...weicloud.com>, Jonathan Corbet
<corbet@....net>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar
<mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Dave Hansen
<dave.hansen@...ux.intel.com>, "maintainer:X86 ARCHITECTURE (32-BIT AND
64-BIT)" <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>, Andy
Lutomirski <luto@...nel.org>, Oleg Nesterov <oleg@...hat.com>, Peter
Zijlstra <peterz@...radead.org>, Xin Li <xin3.li@...el.com>, Arnd Bergmann
<arnd@...db.de>, Andrew Morton <akpm@...ux-foundation.org>, Rick Edgecombe
<rick.p.edgecombe@...el.com>, Kees Cook <keescook@...omium.org>, "Masami
Hiramatsu (Google)" <mhiramat@...nel.org>, Pengfei Xu
<pengfei.xu@...el.com>, Josh Poimboeuf <jpoimboe@...nel.org>, Ze Gao
<zegao2021@...il.com>, "Kirill A. Shutemov"
<kirill.shutemov@...ux.intel.com>, Kai Huang <kai.huang@...el.com>, David
Woodhouse <dwmw@...zon.co.uk>, Brian Gerst <brgerst@...il.com>, Jason
Gunthorpe <jgg@...pe.ca>, Joerg Roedel <jroedel@...e.de>, "Mike Rapoport
(IBM)" <rppt@...nel.org>, Tina Zhang <tina.zhang@...el.com>, Jacob Pan
<jacob.jun.pan@...ux.intel.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>
Subject: Re: [PATCH v1 0/8] x86_64 SandBox Mode arch hooks
On Wed, 14 Feb 2024 10:42:57 -0800
Dave Hansen <dave.hansen@...el.com> wrote:
> On 2/14/24 10:22, Petr Tesařík wrote:
> > Anyway, in the long term I would like to work on gradual decomposition
> > of the kernel into a core part and many self-contained components.
> > Sandbox mode is a useful tool to enforce isolation.
>
> I'd want to see at least a few examples of how this decomposition would
> work and how much of a burden it is on each site that deployed it.
Got it. Are you okay with a couple of examples to illustrate the
concept? Because if you want patches that have been acked by the
respective maintainers, it somehow becomes a chicken-and-egg kind of
problem...
> But I'm skeptical that this could ever work. Ring-0 execution really is
> special and it's _increasingly_ so. Think of LASS or SMAP or SMEP.
I have just answered a similar concern by hpa. In short, I don't think
these features are relevant, because by definition sandbox mode does
not share anything with user mode address space.
> We're even seeing hardware designers add hardware security defenses to
> ring-0 that are not applied to ring-3.
>
> In other words, ring-3 isn't just a deprivileged ring-0, it's more
> exposed to attacks.
>
> > I'd rather fail fast than maintain hundreds of patches in an
> > out-of-tree branch before submitting (and failing anyway).
>
> I don't see any remotely feasible path forward for this approach.
I can live with such decision. But first, I want to make sure that the
concept has been understood correctly. So far, at least some concerns
suggest an understanding that is not quite accurate.
Is this sandbox idea a bit too much out-of-the-box?
Petr T
Powered by blists - more mailing lists