Re: [Ksummit-discuss] [TOPIC] kernel hardening / self-protection / whatever

[Andy Lutomirski <luto@amacapital.net>]

[-- Attachment #1: Type: text/plain, Size: 2549 bytes --]

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:
> >>> 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 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.

[-- Attachment #2: Type: text/html, Size: 3590 bytes --]