Re: [Ksummit-discuss] [TECH TOPIC] Kernel Hardening

[Shuah Khan <shuahkhan@gmail.com>]

On Mon, Aug 24, 2015 at 10:35 AM, Kees Cook <keescook@chromium.org> wrote:
> On Mon, Aug 24, 2015 at 5:29 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Mon, Aug 24, 2015 at 6:20 AM, James Morris <jmorris@namei.org> wrote:
>>
>>> There are also potentially promising approaches to mitigation with other
>>> technologies such as KASan and gcc plugins, as well as evolving hardware
>>> features.
>>
>> What I've discovered when running KASan the last few weeks is that
>> this points back to the question of tests ... I've been using Trinity
>> to find bugs, but it is more likely to kill itself or cause OOM than
>> trigger any boundary overrun bugs.
>>
>> Kselftest may be helpful, but basically any loads that heavily
>> exercise the kernel internals are helpful to harden the kernel.
>> Some of these are custom test suites I suspect. Any good hints
>> for a simple embedded developer like me?
>
> I agree with the sentiment here, but not with the language. Finding
> flaws (which is what selftests, KASan, Trinity, etc do) isn't
> hardening. Hardening is stopping the exploitation of flaws. The
> hardening the kernel needs is about taking away exploitation tools,
> not killing bugs. (Though killing bugs is still great.)

I agree with Kees on this. Kselftest or any other test suites can help
with regression testing and make sure Kernel works the way it should.
Also these tests can tell us if kernel is hardened or not.

Hardening means something different to me. i.e making sure kernel
can protect against attacks and fail gracefully. This is something to
address during design and development process.

>
> As an example, making the kernel code memory read-only means an
> attacker cannot just directly change the kernel's execution path when
> they use an arbitrary memory-writing flaw. (This feature is mostly
> enabled via CONFIG_DEBUG_RODATA, and was very recently added to ARM,
> though isn't at 100% coverage for all the physical memory aliases.)
>

This sounds similar to ExecShield (NX bit) on Intel. Yes this is a good example.

thanks,
-- Shuah