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

[Kees Cook <keescook@chromium.org>]

On Thu, Aug 4, 2016 at 5:12 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> 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's the state of the vmap stacks? Are they just waiting for 4.9 to
open? I haven't seen any further discussion...

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

Yeah, if it looks anything like the arm64 emulation for swapping page
tables in and out, it should work very nicely.

-Kees

-- 
Kees Cook
Nexus Security