Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 28 Nov 2015 10:16:49 +0100
From: Quentin Casasnovas <>
To: Kees Cook <>
Cc: Quentin Casasnovas <>,
        "" <>

On Fri, Nov 27, 2015 at 12:18:55PM -0800, Kees Cook wrote:
> On Thu, Nov 26, 2015 at 9:17 AM, Quentin Casasnovas
> <> 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

> 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

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.


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.