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: <8E695557-1CD2-431A-99CC-49A4E8247BAE@amacapital.net>
Date:   Fri, 26 Apr 2019 10:40:18 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     James Bottomley <James.Bottomley@...senpartnership.com>
Cc:     Dave Hansen <dave.hansen@...el.com>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        linux-kernel@...r.kernel.org,
        Alexandre Chartre <alexandre.chartre@...cle.com>,
        Andy Lutomirski <luto@...nel.org>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.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@...ck.org,
        linux-security-module@...r.kernel.org, x86@...nel.org
Subject: Re: [RFC PATCH 2/7] x86/sci: add core implementation for system call isolation



> On Apr 26, 2019, at 8:19 AM, James Bottomley <James.Bottomley@...senpartnership.com> wrote:
> 
> On Fri, 2019-04-26 at 08:07 -0700, Andy Lutomirski wrote:
>>> On Apr 26, 2019, at 7:57 AM, James Bottomley <James.Bottomley@...se
>>> npartnership.com> wrote:
>>> 
>>>>> On Fri, 2019-04-26 at 07:46 -0700, Dave Hansen wrote:
>>>>> On 4/25/19 2:45 PM, Mike Rapoport wrote:
>>>>> After the isolated system call finishes, the mappings created
>>>>> during its execution are cleared.
>>>> 
>>>> Yikes.  I guess that stops someone from calling write() a bunch
>>>> of times on every filesystem using every block device driver and
>>>> all the DM code to get a lot of code/data faulted in.  But, it
>>>> also means not even long-running processes will ever have a
>>>> chance of behaving anything close to normally.
>>>> 
>>>> Is this something you think can be rectified or is there
>>>> something fundamental that would keep SCI page tables from being
>>>> cached across different invocations of the same syscall?
>>> 
>>> There is some work being done to look at pre-populating the
>>> isolated address space with the expected execution footprint of the
>>> system call, yes.  It lessens the ROP gadget protection slightly
>>> because you might find a gadget in the pre-populated code, but it
>>> solves a lot of the overhead problem.
>> 
>> I’m not even remotely a ROP expert, but: what stops a ROP payload
>> from using all the “fault-in” gadgets that exist — any function that
>> can return on an error without doing to much will fault in the whole
>> page containing the function.
> 
> The address space pre-population is still per syscall, so you don't get
> access to the code footprint of a different syscall.  So the isolated
> address space is created anew for every system call, it's just pre-
> populated with that system call's expected footprint.

That’s not what I mean. Suppose I want to use a ROP gadget in vmalloc(), but vmalloc isn’t in the page tables. Then first push vmalloc itself into the stack. As long as RDI contains a sufficiently ridiculous value, it should just return without doing anything. And it can return right back into the ROP gadget, which is now available.

> 
>> To improve this, we would want some thing that would try to check
>> whether the caller is actually supposed to call the callee, which is
>> more or less the hard part of CFI.  So can’t we just do CFI and call
>> it a day?
> 
> By CFI you mean control flow integrity?  In theory I believe so, yes,
> but in practice doesn't it require a lot of semantic object information
> which is easy to get from higher level languages like java but a bit
> more difficult for plain C.

Yes. As I understand it, grsecurity instruments gcc to create some kind of hash of all function signatures. Then any indirect call can effectively verify that it’s calling a function of the right type. And every return verified a cookie.

On CET CPUs, RET gets checked directly, and I don’t see the benefit of SCI.

> 
>> On top of that, a robust, maintainable implementation of this thing
>> seems very complicated — for example, what happens if vfree() gets
>> called?
> 
> Address space Local vs global object tracking is another thing on our
> list.  What we'd probably do is verify the global object was allowed to
> be freed and then hand it off safely to the main kernel address space.
> 
> 

This seems exceedingly complicated.