linux-kernel - Re: [RFC PATCH 2/7] x86/sci: add core implementation for system call isolation

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]

Message-ID: <20190427084752.GA99668@gmail.com>
Date:   Sat, 27 Apr 2019 10:47:52 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Mike Rapoport <rppt@...ux.ibm.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Alexandre Chartre <alexandre.chartre@...cle.com>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        Jonathan Adams <jwadams@...gle.com>,
        Kees Cook <keescook@...omium.org>,
        Paul Turner <pjt@...gle.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Linux-MM <linux-mm@...ck.org>,
        LSM List <linux-security-module@...r.kernel.org>,
        X86 ML <x86@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH 2/7] x86/sci: add core implementation for system call
 isolation


* Andy Lutomirski <luto@...nel.org> wrote:

> > On Apr 26, 2019, at 2:58 AM, Ingo Molnar <mingo@...nel.org> wrote:
> >
> >
> > * Ingo Molnar <mingo@...nel.org> wrote:
> >
> >> I really don't like it where this is going. In a couple of years I
> >> really want to be able to think of PTI as a bad dream that is mostly
> >> over fortunately.
> >>
> >> I have the feeling that compiler level protection that avoids
> >> corrupting the stack in the first place is going to be lower overhead,
> >> and would work in a much broader range of environments. Do we have
> >> analysis of what the compiler would have to do to prevent most ROP
> >> attacks, and what the runtime cost of that is?
> >>
> >> I mean, C# and Java programs aren't able to corrupt the stack as long
> >> as the language runtime is corect. Has to be possible, right?
> >
> > So if such security feature is offered then I'm afraid distros would be
> > strongly inclined to enable it - saying 'yes' to a kernel feature that
> > can keep your product off CVE advisories is a strong force.
> >
> > To phrase the argument in a bit more controversial form:
> >
> >   If the price of Linux using an insecure C runtime is to slow down
> >   system calls with immense PTI-alike runtime costs, then wouldn't it be
> >   the right technical decision to write the kernel in a language runtime
> >   that doesn't allow stack overflows and such?
> >
> > I.e. if having Linux in C ends up being slower than having it in Java,
> > then what's the performance argument in favor of using C to begin with?
> > ;-)
> >
> > And no, I'm not arguing for Java or C#, but I am arguing for a saner
> > version of C.
> >
> >
> 
> IMO three are three credible choices:
> 
> 1. C with fairly strong CFI protection. Grsecurity has this (supposedly 
> — there’s a distinct lack of source code available), and clang is 
> gradually working on it.
> 
> 2. A safe language for parts of the kernel, e.g. drivers and maybe 
> eventually filesystems.  Rust is probably the only credible candidate. 
> Actually creating a decent Rust wrapper around the core kernel 
> facilities would be quite a bit of work.  Things like sysfs would be 
> interesting in Rust, since AFAIK few or even no drivers actually get 
> the locking fully correct.  This means that naive users of the API 
> cannot port directly to safe Rust, because all the races won't compile
> :)
> 
> 3. A sandbox for parts of the kernel, e.g. drivers.  The obvious 
> candidates are eBPF and WASM.
> 
> #2 will give very good performance.  #3 gives potentially stronger
> protection against a sandboxed component corrupting the kernel overall, 
> but it gives much weaker protection against a sandboxed component 
> corrupting itself.
> 
> In an ideal world, we could do #2 *and* #3.  Drivers could, for 
> example, be written in a language like Rust, compiled to WASM, and run 
> in the kernel.

So why not go for #1, which would still outperform #2/#3, right? Do we 
know what it would take, roughly, and how the runtime overhead looks 
like?

Thanks,

	Ingo