linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Windsor <dave@nullcore.net>
To: Kees Cook <keescook@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Michal Hocko <mhocko@kernel.org>,
	Ben Hutchings <ben@decadent.org.uk>, Willy Tarreau <w@1wt.eu>,
	Hugh Dickins <hughd@google.com>, Oleg Nesterov <oleg@redhat.com>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	Rik van Riel <riel@redhat.com>, Laura Abbott <labbott@redhat.com>,
	Greg KH <greg@kroah.com>, Andy Lutomirski <luto@kernel.org>,
	Linux-MM <linux-mm@kvack.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	kernel-hardening@lists.openwall.com
Subject: Re: [kernel-hardening] Re: [PATCH 0/3] exec: Pin stack limit during exec
Date: Fri, 19 Jan 2018 20:12:40 -0500	[thread overview]
Message-ID: <8BCDD560-66F5-4CF7-97DD-E2E5BE1D13F4@nullcore.net> (raw)
In-Reply-To: <CAGXu5jJjHd9D=20jYnx4PSJHBbRsUOP3bAOJ11yyUWutqVHr2A@mail.gmail.com>

I have some spare cycles; is there any more relevant information outside of this thread?

Thanks,
David

> On Jan 19, 2018, at 5:49 PM, Kees Cook <keescook@chromium.org> wrote:
> 
>> On Tue, Jan 9, 2018 at 12:23 PM, Kees Cook <keescook@chromium.org> wrote:
>> Attempts to solve problems with the stack limit changing during exec
>> continue to be frustrated[1][2]. In addition to the specific issues
>> around the Stack Clash family of flaws, Andy Lutomirski pointed out[3]
>> other places during exec where the stack limit is used and is assumed
>> to be unchanging. Given the many places it gets used and the fact that
>> it can be manipulated/raced via setrlimit() and prlimit(), I think the
>> only way to handle this is to move away from the "current" view of the
>> stack limit and instead attach it to the bprm, and plumb this down into
>> the functions that need to know the stack limits. This series implements
>> the approach. I'd be curious to hear feedback on alternatives.
> 
> Friendly ping -- looking for some people with spare cycles to look
> this over. If people want, I can toss it into -next as part of my kspp
> tree. It's been living happily in 0-day for  2 weeks...
> 
> Thanks!
> 
> -Kees
> 
>> [1] 04e35f4495dd ("exec: avoid RLIMIT_STACK races with prlimit()")
>> [2] 779f4e1c6c7c ("Revert "exec: avoid RLIMIT_STACK races with prlimit()"")
>> [3] to security@kernel.org, "Subject: existing rlimit races?"
> 
> -- 
> Kees Cook
> Pixel Security

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2018-01-20  1:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-09 20:23 Kees Cook
2018-01-09 20:23 ` [PATCH 1/3] exec: Pass stack rlimit into mm layout functions Kees Cook
2018-01-09 20:23 ` [PATCH 2/3] exec: Introduce finalize_exec() before start_thread() Kees Cook
2018-01-09 20:23 ` [PATCH 3/3] exec: Pin stack limit during exec Kees Cook
2018-01-19 22:49 ` [PATCH 0/3] " Kees Cook
2018-01-20  1:12   ` David Windsor [this message]
2018-01-21  1:22     ` [kernel-hardening] " Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8BCDD560-66F5-4CF7-97DD-E2E5BE1D13F4@nullcore.net \
    --to=dave@nullcore.net \
    --cc=Jason@zx2c4.com \
    --cc=akpm@linux-foundation.org \
    --cc=ben@decadent.org.uk \
    --cc=greg@kroah.com \
    --cc=hughd@google.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=labbott@redhat.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mhocko@kernel.org \
    --cc=oleg@redhat.com \
    --cc=riel@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=w@1wt.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox