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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9EF956AB-DF48-4DAA-AB42-0FBC513ECA22@zytor.com>
Date: Wed, 14 Feb 2024 09:29:06 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Petr Tesařík <petr@...arici.cz>
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 8:41:43 AM PST, "Petr Tesařík" <petr@...arici.cz> wrote:
>On Wed, 14 Feb 2024 07:28:35 -0800
>"H. Peter Anvin" <hpa@...or.com> wrote:
>
>> On February 14, 2024 6:52:53 AM PST, 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?  
>> 
>> Seriously. On the surface it looks like a really bad idea – basically an ad hoc, *more* privileged version of user shave.
>
>Hi hpa,
>
>I agree that it kind of tries to do "user mode without user mode".
>There are some differences from actual user mode:
>
>First, from a process management POV, sandbox mode appears to be
>running in kernel mode. So, there is no way to use ptrace(2), send
>malicious signals or otherwise interact with the sandbox. In fact,
>the process can have three independent contexts: user mode, kernel mode
>and sandbox mode.
>
>Second, a sandbox can run unmodified kernel code and interact directly
>with other parts of the kernel. It's not really possible with this
>initial patch series, but the plan is that sandbox mode can share locks
>with the kernel.
>
>Third, sandbox code can be trusted for operations like parsing keys for
>the trusted keychain if the kernel is locked down, i.e. when even a
>process with UID 0 is not on the same trust level as kernel mode.
>
>HTH
>Petr T
>

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

All in all, I cannot see this as anything other than an enormous step in the wrong direction, and it isn't even in the sense of "it is harmless if noone uses it" – you are introducing architectural changes that are most definitely *very* harmful both to maintainers and users.

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