Re: Quick access to stack bounds

[Roland McGrath <roland at redhat dot com>]

> Yes, and that's a problem  With unlimited stacks and PROT_GROW* almost 
> any invalid memory access can be interpreted to belong to a stack.  This 
> is why, I thought, there is something in the kernel to try to 
> differentiate bogus accesses from extensions.

I don't see any code like that in the kernel.

> >> If you propose a kernel change get rid of PROT_GROWS* at the same time.
> >
> > What do you have in mind?
> 
> As kernel extensions?  Richard described the new AT_* constant to tell 
> userlevel about the stack.

No, I thought you meant getting rid of VM_GROWSDOWN internally for the
initial stack vma.  So I was asking what the plan for the main stack would
be if not what we have today.

> I was thinking about completely removing PROT_GROWS*.  Nobody has used 
> it in a decade, I bet.

I'm not entirely clear on which things you are referring to here.

1. PROT_GROWS* flags to mprotect

   This does not change the growth behavior.  It applies the mprotect
   action to the whole stack vma rather than splitting it and applying the
   new protections to only the given page range.  i.e., if you use mprotect
   PROT_ALL|PROT_GROWSDOWN on the stack vma, then PROT_EXEC applies to the
   future growth pages too.  It gets EINVAL if the vma you are touching is
   not already marked GROWS{UP,DOWN} as appropriate--i.e. if it's something
   other than the stack vma.

   _dl_make_stack_executable uses this today.

2. MAP_GROWS* flags to mmap

   With this you can make a fresh mapping that behaves like the initial
   stack vma does.  I don't know of any sensible use for this nor of
   anything that uses it.  (But I have not tried to search the universe.)

3. kernel-internal VM_GROWS* logic for implicit initial stack vma

   To get rid of this would imply getting rid of #1 and #2 too, of course.
   This is what I originally thought you were suggesting.  If so, the
   question is what the kernel should do instead for the implicit initial
   stack vma.  For RLIMIT_STACK that's not RLIM_INFINITY, the obvious
   notion is what I posited: A mapping of RLIMIT_STACK size with a flag
   about not precommitting any pages before faulting them in.  (Or perhaps
   no such flag, and/or perhaps just some madvise-equivalent hint about
   sequential-downwards use patterns.)

> The remaining issue then would be unlimited stacks.

Yes, I don't really know what the plan would be for that.

Note that today's kernel notices whether RLIMIT_STACK is RLIM_INFINITY or
not and based on that chooses (once, at exec time) which algorithm to use
for map-anywhere (i.e. non-MAP_FIXED) mmap calls.  If stack is infinite, it
chooses one that starts at a magic address and goes up from there; if stack
is finite, it chooses one that sticks things up near the base of the stack
and goes down from there.


Thanks,
Roland