Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1684564

Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3

From Michal Hocko <mhocko@kernel.org>
Newsgroups linux.kernel
Subject Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3
Date 2017-07-10 20:40 +0200
Message-ID <u1LLc-94-21@gated-at.bofh.it> (permalink)
References <u0GDU-7Z0-9@gated-at.bofh.it> <u1GLw-5vA-17@gated-at.bofh.it> <u1J6I-6RW-47@gated-at.bofh.it> <u1Jgm-6Vr-17@gated-at.bofh.it> <u1LBw-5E-13@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Mon 10-07-17 11:24:55, Linus Torvalds wrote:
> On Mon, Jul 10, 2017 at 8:59 AM, Michal Hocko <mhocko@kernel.org> wrote:
> >
> > We will always need some gap inforcement.
> 
> Considering the Java issue, that's rather questionable.
> 
> We really can't be breaking libreoffice. That's like a big classic
> no-no - it affects normal users that simply cannot be expected to work
> around it. For them, it's a "my office application no longer works"
> situation, and they just think the system is flaky.

I completely agree that breaking LO is a no-go and we should strive to
find a way around it. One way to go is to increase the ulimit in the LO
start up script I suspect (this can be done in distributions and work
with the upstream LO to be done in future releases). Is it ideal? Not at
all!  But let's face it, the Java usage of the mapping below the stack
is questionable at best (I would dare to call it broken) and I wory to
weaken otherwise useful mitigation based on a fishy application.

> Now, somebody who explicitly raised the stack limit past 24MB and gets
> bit because he also tries to use more than 6M of arguments - that's
> actually a different issue. Let's see if anybody ever even complains,
> and then we might make it a "only for suid binaries" thing.

Sure, I was not worried about suid only binaries. If we should restrict
the argument/env size then they should behave the same way. Otherwise we
just risk oddities. I am just questioning why do we need to cap the
thing at all. I simply do not see what additional protection does it
give.

-- 
Michal Hocko
SUSE Labs

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3 Kees Cook <keescook@chromium.org> - 2017-07-07 21:00 +0200
  Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3 Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-08 00:30 +0200
    Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3 Kees Cook <keescook@chromium.org> - 2017-07-08 04:50 +0200
  Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3 Michal Hocko <mhocko@kernel.org> - 2017-07-10 15:20 +0200
    Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3 Kees Cook <keescook@chromium.org> - 2017-07-10 17:50 +0200
      Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3 Michal Hocko <mhocko@kernel.org> - 2017-07-10 18:00 +0200
        Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3 Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-10 20:30 +0200
          Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3 Michal Hocko <mhocko@kernel.org> - 2017-07-10 20:40 +0200
  Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3 Ben Hutchings <ben@decadent.org.uk> - 2017-07-10 15:50 +0200
    Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3 Kees Cook <keescook@chromium.org> - 2017-07-10 17:40 +0200

csiph-web