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

From: Kees Cook <keescook@chromium.org>
To: Shuah Khan <shuahkhan@gmail.com>
Cc: Emily Ratliff <eratliff@linuxfoundation.org>,
	"ksummit-discuss@lists.linuxfoundation.org"
	<ksummit-discuss@lists.linuxfoundation.org>,
	Shuah Khan <shuahkh@osg.samsung.com>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Kernel Hardening
Date: Tue, 25 Aug 2015 09:15:33 -0700	[thread overview]
Message-ID: <CAGXu5jJp2vEkQ4QmM_Xr=uDrLK_g3f4Nh92MzQmChPDfSXZfYQ@mail.gmail.com> (raw)
In-Reply-To: <CAKocOOP19WowbqaUBxESDd5Q5E4fPYpgPvKTqMn8JhTEhqJEAw@mail.gmail.com>

On Tue, Aug 25, 2015 at 8:15 AM, Shuah Khan <shuahkhan@gmail.com> wrote:
> On Mon, Aug 24, 2015 at 10:35 AM, Kees Cook <keescook@chromium.org> wrote:
>> 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.

Yup! That's exactly the NX bit (or other architecture equivalent). The
trouble tends to be around correctly setting up the kernel memory maps
to actually split up regions and mark the permissions correctly, and
make sure nothing was depending on the side-effects of the old
permissions.

-Kees

-- 
Kees Cook
Chrome OS Security