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

[Kees Cook <keescook@chromium.org>]

On Mon, Jul 11, 2016 at 12:30 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Andy Lutomirski <luto@amacapital.net> writes:
>
>> 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
>>
>>  - Virtually mapped stacks (I'm hoping to have that in for x86 before
>> kernel summit...)
>>
>>  - Refcount
>>
>> I don't how much of this really needs an in-person meeting, but maybe
>> some if it would benefit.
>
> Given the history of the previous work on which much of this kernel
> hardening work is inspired, I think it makes some sense to discuss what
> is needed to get various features ready for mainline.

This is a much larger topic, I think. The work being done already by
the Kernel Self Protection Project is highlighting what's needed to
bring various features into mainline. Generally they require a lot of
chopping up into distinct pieces, expanding their portability to other
architectures, more testing, etc.

> Many kernel hardening features are perceived as having downsides affect
> performance or code maintainability.  Which quite frankly is a security
> issue of another flavor because if something does not work well, and or

Sure, but I think this will be done on a case-by-case basis, as each
thing has wildly different aspects. :)

> is not maintainable after a while it won't get used.  Rarely are we in
> the situation where defense against attack is the most important thing
> that people who are deploying linux are worried about.

Yup, of course. This is why I'm trying to make sure that things have
either near-zero impact or are easily configurable.

-Kees


-- 
Kees Cook
Chrome OS & Brillo Security