From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0A4B5956 for ; Fri, 5 Aug 2016 00:12:05 +0000 (UTC) Received: from mail-ua0-f173.google.com (mail-ua0-f173.google.com [209.85.217.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DF229183 for ; Fri, 5 Aug 2016 00:12:03 +0000 (UTC) Received: by mail-ua0-f173.google.com with SMTP id 35so186419052uap.1 for ; Thu, 04 Aug 2016 17:12:03 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <3aa8df3e-3705-9fd5-640c-37c0be2af561@imgtec.com> <0E98DCC5-01EE-4FA7-B6D4-72772279BDFF@arm.com> From: Andy Lutomirski Date: Thu, 4 Aug 2016 17:12:01 -0700 Message-ID: To: Kees Cook Content-Type: multipart/alternative; boundary=94eb2c1252907c8dec053947ea88 Cc: Jann Horn , Dave Hansen , "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] [TOPIC] kernel hardening / self-protection / whatever List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --94eb2c1252907c8dec053947ea88 Content-Type: text/plain; charset=UTF-8 On Aug 3, 2016 10:54 PM, "Kees Cook" wrote: > > On Wed, Aug 3, 2016 at 10:45 PM, Andy Lutomirski wrote: > > On Wed, Aug 3, 2016 at 10:32 PM, Kees Cook wrote: > >> On Wed, Aug 3, 2016 at 3:53 PM, Catalin Marinas < catalin.marinas@arm.com> wrote: > >>> On 1 Aug 2016, at 00:05, Kees Cook wrote: > >>>> On Sun, Jul 31, 2016 at 2:55 AM, Paul Burton wrote: > >>>>> It would be very interesting to discuss what's needed from arch code for > >>>>> various hardening features, both those currently in mainline & those in > >>>>> development. > >>> > >>> I'm interested in such topic as well, primarily from an arm/arm64 perspective. > >>> > >>>> - Handling userspace/kernelspace memory segregation. (This is the SMAP > >>>> of x86, PAN of ARM, and just native on s390.) For architectures (or > >>>> chipsets within an architecture) that don't support unprivileged > >>>> memory access restrictions in hardware, we must find a way to emulate > >>>> it. (e.g. 32-bit ARM uses Domains, and 64-bit x86 could use PCIDs, > >>>> etc.) Keeping these regions separate is extremely important in > >>>> stopping exploitation. > >>> > >>> For arm64 ARMv8.0 (without hardware PAN), I'm going to post a patch > >>> in a week or so which emulates PAN by switching the user page table (TTBR0) > >>> to the zero page. I guess a similar approach could work for other architectures, > >>> maybe using swapper_pg_dir as the PAN page table. > >> > >> At least on x86 I've heard grumblings that it can be prohibitively > >> expensive due to TLB-flushing, but I'd still like to see an > >> implementation doing it first. :) > > > > No TLB flush needed if we use PCID. Linus will attack you with a > > pitchfork either way, though :) > > Hmm, my asbestos suit won't help me there. I will need to invest in titanium. :) > > The TLB flushing way I can understand being pitchfork-worthy, though > I'm curious why a PCID implementation would be upsetting? I think the problem is the page table switch, not the PCID. > > > It shouldn't be *that* hard to build this thing on top of my PCID > > patchset. I need to dust that off, which I'll do right after vmap > > stacks land and I finish fsgsbase. Sigh, so many things. > > What does your PCID series do? It uses PCID for what it looks like it was designed for: faster context switches. AFAICT it was actually designed for user/kernel switching on Mac OS X, which, if true, would explain some design oddities. --94eb2c1252907c8dec053947ea88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Aug 3, 2016 10:54 PM, "Kees Cook" <keescook@chromium.org> wrote:
>
> On Wed, Aug 3, 2016 at 10:45 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> > On Wed, Aug 3, 2016 at 10:32 PM, Kees Cook <keescook@chromium.org> wrote:
> >> On Wed, Aug 3, 2016 at 3:53 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:<= br> > >>> On 1 Aug 2016, at 00:05, Kees Cook <keescook@chromium.org> wrote:
> >>>> On Sun, Jul 31, 2016 at 2:55 AM, Paul Burton <paul.burton@imgtec.com> wrote:=
> >>>>> It would be very interesting to discuss what'= s needed from arch code for
> >>>>> various hardening features, both those currently = in mainline & those in
> >>>>> development.
> >>>
> >>> I'm interested in such topic as well, primarily from = an arm/arm64 perspective.
> >>>
> >>>> - Handling userspace/kernelspace memory segregation. = (This is the SMAP
> >>>> of x86, PAN of ARM, and just native on s390.) For arc= hitectures (or
> >>>> chipsets within an architecture) that don't suppo= rt unprivileged
> >>>> memory access restrictions in hardware, we must find = a way to emulate
> >>>> it. (e.g. 32-bit ARM uses Domains, and 64-bit x86 cou= ld use PCIDs,
> >>>> etc.) Keeping these regions separate is extremely imp= ortant in
> >>>> stopping exploitation.
> >>>
> >>> For arm64 ARMv8.0 (without hardware PAN), I'm going t= o post a patch
> >>> in a week or so which emulates PAN by switching the user = page table (TTBR0)
> >>> to the zero page. I guess a similar approach could work f= or other architectures,
> >>> maybe using swapper_pg_dir as the PAN page table.
> >>
> >> At least on x86 I've heard grumblings that it can be proh= ibitively
> >> expensive due to TLB-flushing, but I'd still like to see = an
> >> implementation doing it first. :)
> >
> > No TLB flush needed if we use PCID.=C2=A0 Linus will attack you w= ith a
> > pitchfork either way, though :)
>
> Hmm, my asbestos suit won't help me there. I will need to invest i= n titanium. :)
>
> The TLB flushing way I can understand being pitchfork-worthy, though > I'm curious why a PCID implementation would be upsetting?

I think the problem is the page table switch, not the PCID.<= /p>

>
> > It shouldn't be *that* hard to build this thing on top of my = PCID
> > patchset.=C2=A0 I need to dust that off, which I'll do right = after vmap
> > stacks land and I finish fsgsbase.=C2=A0 Sigh, so many things. >
> What does your PCID series do?

It uses PCID for what it looks like it was designed for: fas= ter context switches.

AFAICT it was actually designed for user/kernel switching on= Mac OS X, which, if true, would explain some design oddities.

--94eb2c1252907c8dec053947ea88--