Date: Sat, 28 Nov 2015 10:16:49 +0100 From: Quentin Casasnovas <quentin.casasnovas@...cle.com> To: Kees Cook <keescook@...omium.org> Cc: Quentin Casasnovas <quentin.casasnovas@...cle.com>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com> Subject: Re: status: GRKERNSEC_KSTACKOVERFLOW On Fri, Nov 27, 2015 at 12:18:55PM -0800, Kees Cook wrote: > On Thu, Nov 26, 2015 at 9:17 AM, Quentin Casasnovas > <quentin.casasnovas@...cle.com> wrote: > > > > 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? > I couldn't find anything in Documentation/ but the flag is documented in include/linux/vmalloc.h. I found it by looking at the vmap() code directly. > > 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? > AFAIU (which might not be very far!), the size is grown in get_vm_area_caller() but then only the *requested* size is mapped in map_vm_area(). On x86-64, where we have the IST stack, that means as soon as we access below the currently mapped stack, we'll get a page fault, which will be handled by vmalloc_fault(), and since no PTE is present for that page, that should cause an Oops. On x86, I believe a page fault when accessing below the stack would cause a double fault, as there won't be any stack switching since we're coming from ring0 (and there isn't a stack switch on exception when there isn't a privilege change), so the first page fault would cause a second fault when the CPU tries to push the context on the same stack. Quentin
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.