On Thu, Jul 6, 2017 at 10:15 PM, Kees Cook <keesc...@chromium.org> wrote:
>
> I always say this backwards. :P Default is top-down (allocate at high
> addresses and work down toward low). With unlimited stack, allocations
> start at low addresses and work up. Here's the results (shown with
> randomize_va_space sysctl set to 0):
But this doesn't affect the stack layout itself.
So we could do the stack copying without much caring, because that
happens first, right?
So I think we can do all the envp/argv copying first, and then - as we
change the credentials, change the rlimit. And the string copies
wouldn't need to care much - although I guess they are also fine
checking against a possible *smaller* stack rlimit, which is actually
what we'd want.
And I think the credentials switch (which is the point of no return
anyway) happens before we start mmap'ing the executable etc. We used
to have some odd code there and do it in the completely wrong order
(checking that the binary was executable for the *old* user, which
makes no sense, iirc)
So I'm getting the sense that none of this should be a problem.
But it's entirely possible that I missed something, and am just full
of shit. Our execve() path has traditionally been very hard to read.
It's actually gotten a bit better, but the whole "jump back and forth
between the generic fs/exec.c code and the binfmt code" is certainly
still there.
Linus
