[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5j+ttTK5w-i7wituvrrkSXexta-3VWktBi1t5GC82iBQFw@mail.gmail.com>
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.
