[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240216170805.0d0decd5@meshulam.tesarici.cz>
Date: Fri, 16 Feb 2024 17:08:05 +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>, David Howells
<dhowells@...hat.com>, Petr Tesarik <petr.tesarik1@...wei-partners.com>
Subject: Re: [RFC 0/8] PGP key parser using SandBox Mode
On Fri, 16 Feb 2024 07:38:30 -0800
Dave Hansen <dave.hansen@...el.com> wrote:
> On 2/16/24 07:24, Petr Tesarik wrote:
> > While I started working on my development branch to illustrate how
> > SandBox Mode could be enhanced to allow dynamic memory allocation and
> > other features necessary to convert some existing code, my colleague
> > Roberto Sassu set out and adapted a PGP key parser to run in a sandbox.
> >
> > Disclaimer:
> >
> > The code had to be rearranged in order to avoid memory allocations
> > and crypto operations in the sandbox. The code might contain errors.
>
> I'm confused by this. The kernel doesn't (appear to) have a PGP parser
> today. So are you saying that it *should* have one and it's only
> feasible if its confined in a sandbox?
I'm sorry if this is confusing. Yes, your understanding is correct.
This patch series demonstrates that SBM (even in the initial version
that was submitted) allows to write a PGP parser which can survive
memory safety bugs withoug compromising the rest of the kernel.
> A much more powerful example would be to take something that the kernel
> has already and put it in a sandbox. That would show us how difficult
> it is to sandbox something versus just doing it _normally_ in the kernel.
That's what I have also tested as a PoC with an earlier version of my
patch series and a few quick hacks on top. As it happens, that code
on top needs to be adapted for the current patch series, so I cannot
post it just yet. Please, stay tuned.
> As it stands, I fear this was just the largest chunk of sandbox code
> that was laying around and it seemed like a good idea to just chuck
> ~1400 lines of code over the wall at a huge cc list.
You asked for some real-world scenarios, and this should be one.
Another is on the way, but see above why it takes a bit of time.
I am not trying to claim I'm the smartest person on this planet. I can
accept it if there is a fundamental flaw in my approach. Yet, I'd be
glad if somebody can make me a favor and at least hint at what exactly
is the issue with it. I have to admit this thing is still not quite
clear to me. I would be sad if I couldn't learn from this experience.
Petr T
Powered by blists - more mailing lists