On Thu, Jul 6, 2017 at 10:15 PM, Kees Cook <keesc...@chromium.org> wrote: > On Thu, Jul 6, 2017 at 10:10 PM, Kees Cook <keesc...@chromium.org> wrote: >> On Thu, Jul 6, 2017 at 9:48 PM, Andy Lutomirski <l...@kernel.org> wrote: >>> How about a much simpler solution: don't read rlimit at all in >>> copy_strings(), let alone try to enforce it. Instead, just before the >>> point of no return, check how much stack space is already used and, if >>> it's more than an appropriate threshold (e.g. 1/4 of the rlimit), >>> abort. Sure, this adds overhead if we're going to abort, but does >>> that really matter? >> >> We should avoid using up tons of memory and then failing. Better to >> cap it as we use it. Plumbing a sane value into this shouldn't be hard >> at all. Just making this a hardcoded 2MB seems sane (1/4 of 8MB).
Aren't there real use cases that use many megs of arguments? We could probably get away with saying max(rlimit(RLIMIT_STACK), 2MB) as long as we make sure later on that we don't screw up if we've overallocated? >> >>> I don't see why using rlimit for layout control makes any sense >>> whatsoever. Is there some historical reason we need that? As far as >>> I can see (on insufficient inspection) is that the kernel is trying to >>> guarantee that, if we have so much arg crap that our remaining stack >>> is less than 128k, then we don't exceed our limit by a little bit. >> >> IIUC, this is a big deal on 32-bit. Unlimited stack triggers top-down >> mmap instead of bottom-up. I mean, I'd be delighted to get rid of >> this, but I thought it was relied on by userspace. > > 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): Uhh, crikey! Where's the code that does that?
