Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: [RFC PATCH 2/7] x86/sci: add core implementation for system call isolation
From:   Andy Lutomirski <luto@amacapital.net>
In-Reply-To: <1556304567.2833.62.camel@HansenPartnership.com>
Date:   Fri, 26 Apr 2019 12:22:01 -0700
Cc:     Dave Hansen <dave.hansen@intel.com>,
        Mike Rapoport <rppt@linux.ibm.com>,
        linux-kernel@vger.kernel.org,
        Alexandre Chartre <alexandre.chartre@oracle.com>,
        Andy Lutomirski <luto@kernel.org>,
        Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
        Jonathan Adams <jwadams@google.com>,
        Kees Cook <keescook@chromium.org>,
        Paul Turner <pjt@google.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>, linux-mm@kvack.org,
        linux-security-module@vger.kernel.org, x86@kernel.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <BFDE56E4-6763-40C2-8E8A-661A22B4C0A7@amacapital.net>
References: <1556228754-12996-1-git-send-email-rppt@linux.ibm.com> <1556228754-12996-3-git-send-email-rppt@linux.ibm.com> <627d9321-466f-c4ed-c658-6b8567648dc6@intel.com> <1556290658.2833.28.camel@HansenPartnership.com> <54090243-E4C7-4C66-8025-AFE0DF5DF337@amacapital.net> <1556291961.2833.42.camel@HansenPartnership.com> <8E695557-1CD2-431A-99CC-49A4E8247BAE@amacapital.net> <1556304567.2833.62.camel@HansenPartnership.com>
To:     James Bottomley <James.Bottomley@hansenpartnership.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Apr 26, 2019, at 11:49 AM, James Bottomley <James.Bottomley@hansenpartn=
ership.com> wrote:
>=20
> On Fri, 2019-04-26 at 10:40 -0700, Andy Lutomirski wrote:
>>> On Apr 26, 2019, at 8:19 AM, James Bottomley <James.Bottomley@hanse
>>> npartnership.com> wrote:
>>>=20
>>> On Fri, 2019-04-26 at 08:07 -0700, Andy Lutomirski wrote:
>>>>> On Apr 26, 2019, at 7:57 AM, James Bottomley
>>>>> <James.Bottomley@hansenpartnership.com> wrote:
>>>>>=20
>>>>>>> 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.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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?
>>>>>=20
>>>>> 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.
>>>>=20
>>>> I=E2=80=99m not even remotely a ROP expert, but: what stops a ROP paylo=
ad
>>>> from using all the =E2=80=9Cfault-in=E2=80=9D gadgets that exist =E2=80=
=94 any function
>>>> that can return on an error without doing to much will fault in
>>>> the whole page containing the function.
>>>=20
>>> 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.
>>=20
>> That=E2=80=99s not what I mean. Suppose I want to use a ROP gadget in
>> vmalloc(), but vmalloc isn=E2=80=99t 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.
>=20
> Yes, it's not perfect, but stack space for a smashing attack is at a
> premium and now you need two stack frames for every gadget you chain
> instead of one so we've halved your ability to chain gadgets.
>=20
>>>> 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=E2=80=99t we just do CFI
>>>> and call it a day?
>>>=20
>>> 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.
>>=20
>> 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=E2=80=99s calling a function of the right type=
.
>> And every return verified a cookie.
>>=20
>> On CET CPUs, RET gets checked directly, and I don=E2=80=99t see the benef=
it
>> of SCI.
>=20
> Presumably you know something I don't but I thought CET CPUs had been
> planned for release for ages, but not actually released yet?

I don=E2=80=99t know any secrets about this, but I don=E2=80=99t think it=E2=
=80=99s released. Last I checked, it didn=E2=80=99t even have a final public=
 spec.

>=20
>>>> On top of that, a robust, maintainable implementation of this
>>>> thing seems very complicated =E2=80=94 for example, what happens if
>>>> vfree() gets called?
>>>=20
>>> 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.
>>=20
>> This seems exceedingly complicated.
>=20
> It's a research project: we're exploring what's possible so we can
> choose the techniques that give the best security improvement for the
> additional overhead.
>=20

:)=