linux-kernel - Re: [PATCH v1 0/8] x86_64 SandBox Mode arch hooks

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: Thu, 15 Feb 2024 00:16:13 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Petr Tesařík <petr@...arici.cz>,
        Xin Li <xin@...or.com>
CC: Dave Hansen <dave.hansen@...el.com>,
        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>,
        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 February 14, 2024 10:59:32 PM PST, "Petr Tesařík" <petr@...arici.cz> wrote:
>On Wed, 14 Feb 2024 10:52:47 -0800
>Xin Li <xin@...or.com> wrote:
>
>> On 2/14/2024 10:22 AM, Petr Tesařík wrote:
>> > On Wed, 14 Feb 2024 06:52:53 -0800
>> > Dave Hansen <dave.hansen@...el.com> wrote:
>> >   
>> >> On 2/14/24 03:35, Petr Tesarik wrote:  
>> >>> This patch series implements x86_64 arch hooks for the generic SandBox
>> >>> Mode infrastructure.  
>> >>
>> >> I think I'm missing a bit of context here.  What does one _do_ with
>> >> SandBox Mode?  Why is it useful?  
>> > 
>> > I see, I split the patch series into the base infrastructure and the
>> > x86_64 implementation, but I forgot to merge the two recipient lists.
>> > :-(
>> > 
>> > 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.
>> > 
>> > In its current form, sandbox mode is too limited for that, but I'm
>> > trying to find some balance between "publish early" and reaching a
>> > feature level where some concrete examples can be shown. I'd rather
>> > fail fast than maintain hundreds of patches in an out-of-tree branch
>> > before submitting (and failing anyway).
>> > 
>> > Petr T
>> >   
>> 
>> What you're proposing sounds a gigantic thing, which could potentially
>> impact all subsystems.
>
>True. Luckily, sandbox mode allows me to move gradually, one component
>at a time.
>
>>  Unless you prove it has big advantages with real
>> world usages, I guess nobody even wants to look into the patches.
>> 
>> BTW, this seems another attempt to get the idea of micro-kernel into
>> Linux.
>
>We know it's not feasible to convert Linux to a micro-kernel. AFAICS
>that would require some kind of big switch, affecting all subsystems at
>once.
>
>But with a growing code base and more or less constant bug-per-LOC rate,
>people will continue to come up with some ideas how to limit the
>potential impact of each bug. Logically, one of the concepts that come
>to mind is decomposition.
>
>If my attempt helps to clarify how such decomposition should be done to
>be acceptable, it is worthwile. If nothing else, I can summarize the
>situation and ask Jonathan if he would kindly accept it as a LWN
>article...
>
>Petr T
>

I have been thinking more about this, and I'm more than ever convinced that exposing kernel memory to *any* kind of user space is a really, really bad idea. It is not a door we ever want to open; once that line gets muddled, the attack surface opens up dramatically.

And, in fact, we already have a sandbox mode in the kernel – it is called eBPF.