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

[Kees Cook <keescook@chromium.org>]

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

>>> For example MIPS systems are currently showing the "This architecture does
>>> not have kernel memory protection." message since d2aa1acad22f (which to a
>>> user sounds pretty dire as though user code can freely access kernel data)
>>> and which I'd like for MIPS to implement the security to avoid. However
>>> because TLB refills are performed by software it's non-trivial, since we
>>> generally rely upon the kernel being placed in an unmapped region of the
>>> virtual address space & being unmapped there is no TLB entry to mark
>>> read-only.
>>
>> This is actually from the perspective of the kernel, so when the
>> kernel code is running, it's mapped, and those entries should all be
>> marked read-only. As I mentioned above, we need to consider W^X memory
>> permissions a fundamental security protection, and architectures
>> should make sure this is completely fixed.
>
> On arm64 we have such feature in hardware: the WXN (write execute never)
> bit in SCTLR_EL1. However, this would affect user space as well, so it needs to
> be switched only when entering the kernel to avoid ABI breakage. I don't have
> the ARM specs at hand but one possible complication is the WXN bit
> being cached in the TLB (and invalidating the TLBs on kernel entry/exit
> is not practical).

Oh, that's even more literal W^X than I was expecting. I just meant
having clean page permissions on the kernel text. If we could actually
put WXN to use, that would be very interesting. (Though I guess I
don't see its advantage over just being non-executable?)

>> (And that is stays that
>> way: x86 actually scans kernel memory permissions at boot now to make
>> sure no writable and executable regions have appeared.)
>
> That's probably a good enough workaround without additional hardware support.
>
> BTW, while not a kernel security feature, I've been asked in the past to enable
> execute-only (no read) permissions on arm64 (e.g. mmap(PROT_EXEC)).
> I have a simple patch for this, though I'm not 100% sure about user ABI implications.
> So far I'm not aware of any user application using PROT_EXEC only and also
> expecting PROT_READ.

x86 is working on this too, and IIRC, they uncovered some "fun" ELF
corner cases. I've added Dave for some more background...

-Kees

-- 
Kees Cook
Brillo & Chrome OS Security