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

[Andy Lutomirski <luto@amacapital.net>]

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

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.