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

[Kees Cook <keescook@chromium.org>]

On Sun, Jul 31, 2016 at 2:55 AM, Paul Burton <paul.burton@imgtec.com> wrote:
> 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.

Yeah, there are a number of arch-specific things on my radar:

- Standardizing copy_*_user() infrastructure. Each architecture does
their usercopy work in slightly different ways, and hooking it for
things like KASan and hardened usercopy can be weird and error-prone.
What's landing in arm64 is, I think, likely the start of what things
should look like for other architectures: there is a low-level
function (__arch_copy_*_user) that does the actual work of the copy.
Above that needs to be the place to hook KASan and hardened usercopy,
but still within the __copy* and copy* functions. (And x86 has a
single-underscore _copy* set of functions too!) Deciding the ordering
of KASan/hardened-usercopy vs access_ok checks may be worth discussing
too. For example, it's silly to check hardened-usercopy first if
access_ok is going to reject it.

- Cleaning up CONFIG_DEBUG_RODATA. This config should not be called
"debug", and, frankly, it should be mandatory for all architectures.
But (as you mention below) we need to sort out each architecture's
various capabilities in this regard. Some use delayed RO-marking (e.g.
x86, arm), some do it at load time (e.g. s390). As part of this clean
up, making sure the __ro_after_init section is being handled correctly
is needed too (and more people need to start using it). But we've got
to have correct memory protections in kernel memory; this is a
fundamental protection.

- Supporting gcc plugins. Validating each architecture correctly
supports the gcc plugin infrastructure is important since a number of
features may start landing there (already we'll have a latent entropy
plugin that can help especially embedded devices).

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

- Significant reduction in kernel memory attack surface by marking
rarely-changed function pointers as read-only. We need architectures
to have a way to make (uncommonly changed) function pointers
temporarily writable so that they are read-only (see
CONFIG_DEBUG_RODATA above) during most of their lifetime, thus
removing them as viable attack targets. There is nothing implemented
for this in the kernel yet.

- Stacks without thread_info and with guard pages. Each architecture
needs to keep sensitive values off the kernel stack so that they can't
be targeted via stack-based attacks (e.g. via offsets or exhaustion),
and that faulting pages should live at either end to catch exhaustion
or large writes/reads trying to reach into other stacks. x86 is
starting to work on this now.

- Atomic overflow handling. Each architecture needs to provide a way
to catch atomic_t when it wraps around. This isn't implemented
anywhere in the kernel yet, but it'll need per-architecture support.
Some background on the rationale and the work involved (from the
perspective of this protection in PaX/Grsecurity, which has support
for x86, arm, mips, powerpc, and sparc) can be read here:
https://forums.grsecurity.net/viewtopic.php?f=7&t=4173

- Kernel ASLR: each architecture should (especially 64-bit ones)
separately randomize the base address of the kernel text, kernel
modules, and any large memory areas. Already x86, arm64, and MIPS are
doing base text address and module ASLR, with x86 now landing memory
ASLR too. Getting more architectures doing this would be a nice
addition. (And this will raise the need to provide better kernel
memory address exposure handling, since there are still so many ways
to leak the KASLR offsets. But breaking this catch-22 is important:
we'll never fix exposures if they're not important to fix, and we'll
never implement KASLR if there are so many exposures.)

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

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

Yeah, I'd love to get MIPS added to the hardened usercopy series: I
just hadn't had time to dig in. It _should_ be pretty straight
forward. If following the arm64 example is desired, the changes are
pretty clear in the arm64 patch:
http://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/commit/?h=for-linus/usercopy&id=faf5b63e294151d6ac24ca6906d6f221bd3496cd
If you have time to look it over and send a patch, I'd love to land it. :)

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

I did a bit of a brain-dump into here already:
https://www.kernel.org/doc/Documentation/security/self-protection.txt

For the things that are implemented in the kernel, making sure each
architecture fully supports them would be a good first step. I'd like
to make a little chart of feature vs architecture, but it's a little
hard to compile, since it tends to have a third dimension: chipset.
For example, the PAN/SMAP protection (emulated or in hardware) looks
like this:
http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_data_usage#Mitigations
so it can be a bit of an eye-chart. :P

There is, of course, more than everything above, but I think these
things will keep us busy for a while. :)

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security