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

[Paul Burton <paul.burton@imgtec.com>]

On 11/07/16 18:53, Kees Cook wrote:
> On Mon, Jul 11, 2016 at 12:28 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> Are there useful things to discuss in person about hardening?  (I
>> don't want to bikeshed about the name at the kernel summit if we can
>> possibly avoid it.)
>>
>> Plausible sub-topics include:
>>
>>  - "USERCOPY" hardening
>
> The whitelisting stuff might be interesting, but I think it's mostly
> about standardizing how architectures define their *copy_*_user()
> implementations so that things like KASan and now the hardening
> infrastructure can hook it reliably.
>
>>  - Virtually mapped stacks (I'm hoping to have that in for x86 before
>> kernel summit...)
>
> Yeah, this should just go in. :) Perhaps a discussion for other
> architectures, and the specific requirements (which are mostly well
> documented, excepting some notes on stuff like the guard page at
> either end, etc).

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.

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.

Usercopy sounds like an interesting one for us too, with the MIPS 
copy_*_user implementations ripe for some cleanup.

It would be interesting to hear from people focused on security what 
their requirements, current & coming soon, from arch code are.

Thanks,
     Paul