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

[Catalin Marinas <catalin.marinas@arm.com>]

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. 

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

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


(Sorry for the email formatting, I'm on holiday and with only a phone as communication device)

-- 
Catalin