Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 27 Nov 2015 12:18:55 -0800
From: Kees Cook <keescook@...omium.org>
To: Quentin Casasnovas <quentin.casasnovas@...cle.com>
Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: status: GRKERNSEC_KSTACKOVERFLOW

On Thu, Nov 26, 2015 at 9:17 AM, Quentin Casasnovas
<quentin.casasnovas@...cle.com> wrote:
> On Thu, Nov 26, 2015 at 12:45:42AM +0100, Quentin Casasnovas wrote:
>> On Tue, Nov 24, 2015 at 11:10:09AM -0800, Kees Cook wrote:
>> > Hi,
>> >
>>
>> Hi Kees,
>>
>> > I just wanted to check in and see how progress was going on the stack
>> > overflow feature. Anything we can help with?
>> >
>>
>> Sorry for not following up on this, I've been busy and haven't had the time
>> to finish it properly.  I've pushed an initial WIP break up of the
>> KSTACK_OVERFLOW feature on my github:
>>
>>   https://github.com/casasnovas/linux/tree/quentin-split-kstackoverflow
>>
>> This is far from being complete though, and hasn't been cleaned at all.  I
>> didn't share it earlier because I don't think I fully understand it and
>> haven't tested it yet.  In "short", there's mention of guard pages in the
>> Kconfig help:
>>
>>   If you say Y here, the kernel's process stacks will be allocated with
>>   vmalloc instead of the kernel's default allocator.  This introduces guard
>>                                                                       ^^^^^
>>   pages that in combination with the alloca checking of the STACKLEAK
>>   ^^^^^
>>   feature prevents all forms of kernel process stack overflow abuse.  Note
>>   that this is different from kernel stack buffer overflows. """
>>
>> And I couldn't find anything about it in the code.  Maybe it's just coming
>> from a mis-interpretation of the above text, but I was expecting this to
>> mean there would be a PROT_NONE guard page after the end of the stack, so
>> that read/writes below it could be trapped.  It could also be that I missed
>> some parts in my initial break-up or simply am missing something.
>>
>
> Alright, there's a guard page by default when using vmap() unless
> VM_NO_GUARD is in the flags.  I had a feeling I was missing some bits.. ;)

Is this documented anywhere in Documentation? Reading the code
quickly, I don't understand what actually makes this a guard page. It
looks like the requested size is just grown. Is it actually set up in
a way that'll trap if it that page gets touched?

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.