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

[Andy Lutomirski]

On Thu, Sep 8, 2016 at 4:54 PM, Kees Cook <keescook at chromium.org> wrote:
> On Thu, Aug 4, 2016 at 5:12 PM, Andy Lutomirski <luto at amacapital.net> wrote:
>> On Aug 3, 2016 10:54 PM, "Kees Cook" <keescook at chromium.org> wrote:
>>>
>>> On Wed, Aug 3, 2016 at 10:45 PM, Andy Lutomirski <luto at amacapital.net>
>>> wrote:
>>> > On Wed, Aug 3, 2016 at 10:32 PM, Kees Cook <keescook at chromium.org>
>>> > wrote:
>>> >> On Wed, Aug 3, 2016 at 3:53 PM, Catalin Marinas
>>> >> <catalin.marinas at arm.com> wrote:
>>> >>> On 1 Aug 2016, at 00:05, Kees Cook <keescook at chromium.org> wrote:
>>> >>>> On Sun, Jul 31, 2016 at 2:55 AM, Paul Burton <paul.burton at 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...

Vmapped stacks themselves are in tip:x86/asm.  The thread_info cleanup
isn't yet, though.  I'm guessing that Ingo is still wrangling the
patches into his queue.