From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Cyrus-Session-Id: sloti22d1t05-563198-1516402163-2-2036425090701688950 X-Sieve: CMU Sieve 3.0 X-Spam-known-sender: no X-Spam-score: 0.0 X-Spam-hits: BAYES_00 -1.9, HEADER_FROM_DIFFERENT_DOMAINS 0.25, RCVD_IN_DNSWL_NONE -0.0001, RCVD_IN_MSPIKE_H2 -0.001, SPF_PASS -0.001, T_RP_MATCHES_RCVD -0.01, LANGUAGES en, BAYES_USED global, SA_VERSION 3.4.0 X-Spam-source: IP='209.85.217.171', Host='mail-ua0-f171.google.com', Country='US', FromHeader='org', MailFrom='com' X-Spam-charsets: plain='UTF-8' X-Resolved-to: greg@kroah.com X-Delivered-to: greg@kroah.com X-Mail-from: keescook@google.com ARC-Seal: i=1; a=rsa-sha256; cv=none; d=messagingengine.com; s=arctest; t=1516402163; b=Fut1A5GurUlJ6AHplLQfySqvV2datKZ1vDJWquSVATAasu6 1Rq5Wx3jaiSaJY97MXMQwzn/ga/bHdPAoF60xshPzLsslZXdUoLc9+kzUKg/gwNg f7PX1CExTtUX3XrpDpJCTZP4ewDwEGz9sg7yUzV1ya29CBBCQB5Kjz+olPyxWvFP XvuzW0gD94XS8LmTNeUfYmgkpGHD2vlIeHy9TXiVAkCgYD02FjaAs6h1O3dyrosJ T1nXGNAKU7+TmNU6eMdRboYxWfdKXY2XnEWiW0yS5k+J7U72TOGFWnKVKmtmfARC GTnU12p5plJ+rrMipesknm03gkpQHLkY3UdvXBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=mime-version:sender:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; s= arctest; t=1516402163; bh=ctbhEN2g1StA4UQikzHsJKtRYEfQaa90ZuoVx4 28pLQ=; b=smVVS0IuTchtfgNF30BpWxilVVA2qHLecjRmc1aagoq1rZfAJrLA8v 0LacmfpXxr74ediYN/6nYbw2TRPvkVkYLa+kPhiuk0vFju+ivpUGJwSMIVBICmBt i5vxh1eXzZ5HaV4FtG+mq0ZtEZJs1hb4wJbMXXyUNi0euhuoDNYXZJSNtY8PAsVx kCJbnFnfx23bFzfKBAO7BHpm/O7tF9DRG7X8Ai2r3W+HIg+bud0kRdZ1rDIu8ZCQ rtpo4m3BqRis5CXyhKIbnO7mRM9+43hJRfFOxlmq6FFfqVE1P2YZzBkhMKhwnIi7 T1gbUx9aIsiqqnn2t2+okI27mexNgkqg== ARC-Authentication-Results: i=1; mx5.messagingengine.com; arc=none (no signatures found); dkim=pass (1024-bit rsa key sha256) header.d=chromium.org header.i=@chromium.org header.b=Ee5f5Zq8 x-bits=1024 x-keytype=rsa x-algorithm=sha256 x-selector=google; dkim=pass (2048-bit rsa key sha256) header.d=google.com header.i=@google.com header.b=heRE7aQp x-bits=2048 x-keytype=rsa x-algorithm=sha256 x-selector=20161025; dmarc=pass (p=none,d=none) header.from=chromium.org; iprev=pass policy.iprev=209.85.217.171 (mail-ua0-f171.google.com); spf=pass smtp.mailfrom=keescook@google.com smtp.helo=mail-ua0-f171.google.com; x-aligned-from=fail; x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=T+t4ntak; x-ptr=pass x-ptr-helo=mail-ua0-f171.google.com x-ptr-lookup=mail-ua0-f171.google.com; x-return-mx=pass smtp.domain=google.com smtp.result=pass smtp_is_org_domain=yes header.domain=chromium.org header.result=pass header_is_org_domain=yes; x-tls=pass version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128 Authentication-Results: mx5.messagingengine.com; arc=none (no signatures found); dkim=pass (1024-bit rsa key sha256) header.d=chromium.org header.i=@chromium.org header.b=Ee5f5Zq8 x-bits=1024 x-keytype=rsa x-algorithm=sha256 x-selector=google; dkim=pass (2048-bit rsa key sha256) header.d=google.com header.i=@google.com header.b=heRE7aQp x-bits=2048 x-keytype=rsa x-algorithm=sha256 x-selector=20161025; dmarc=pass (p=none,d=none) header.from=chromium.org; iprev=pass policy.iprev=209.85.217.171 (mail-ua0-f171.google.com); spf=pass smtp.mailfrom=keescook@google.com smtp.helo=mail-ua0-f171.google.com; x-aligned-from=fail; x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=T+t4ntak; x-ptr=pass x-ptr-helo=mail-ua0-f171.google.com x-ptr-lookup=mail-ua0-f171.google.com; x-return-mx=pass smtp.domain=google.com smtp.result=pass smtp_is_org_domain=yes header.domain=chromium.org header.result=pass header_is_org_domain=yes; x-tls=pass version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128 X-Google-Smtp-Source: AH8x226bVlPbs5+c1C2ofAEC4okbs7Cq9ey/acyrdJS1+VwKCR3va5/AoUNkNKEDS2kAeS/NE/HKvlM79NsAlB6rHKE= MIME-Version: 1.0 Sender: keescook@google.com In-Reply-To: <1515529383-35695-1-git-send-email-keescook@chromium.org> References: <1515529383-35695-1-git-send-email-keescook@chromium.org> From: Kees Cook Date: Fri, 19 Jan 2018 14:49:20 -0800 X-Google-Sender-Auth: PiAgdAAX1W8NULGsisSVabDQUn8 Message-ID: Subject: Re: [PATCH 0/3] exec: Pin stack limit during exec To: Andrew Morton Cc: Kees Cook , Linus Torvalds , Michal Hocko , Ben Hutchings , Willy Tarreau , Hugh Dickins , Oleg Nesterov , "Jason A. Donenfeld" , Rik van Riel , Laura Abbott , Greg KH , Andy Lutomirski , Linux-MM , linux-arch , LKML , kernel-hardening@lists.openwall.com Content-Type: text/plain; charset="UTF-8" X-getmail-retrieved-from-mailbox: INBOX X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Tue, Jan 9, 2018 at 12:23 PM, Kees Cook 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Subject: Re: [PATCH 0/3] exec: Pin stack limit during exec Date: Fri, 19 Jan 2018 14:49:20 -0800 Message-ID: References: <1515529383-35695-1-git-send-email-keescook@chromium.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <1515529383-35695-1-git-send-email-keescook@chromium.org> Sender: owner-linux-mm@kvack.org To: Andrew Morton Cc: Kees Cook , Linus Torvalds , Michal Hocko , Ben Hutchings , Willy Tarreau , Hugh Dickins , Oleg Nesterov , "Jason A. Donenfeld" , Rik van Riel , Laura Abbott , Greg KH , Andy Lutomirski , Linux-MM , linux-arch , LKML , kernel-hardening@lists.openwall.com List-Id: linux-arch.vger.kernel.org On Tue, Jan 9, 2018 at 12:23 PM, Kees Cook 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 Sender: keescook@google.com In-Reply-To: <1515529383-35695-1-git-send-email-keescook@chromium.org> References: <1515529383-35695-1-git-send-email-keescook@chromium.org> From: Kees Cook Date: Fri, 19 Jan 2018 14:49:20 -0800 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: [kernel-hardening] Re: [PATCH 0/3] exec: Pin stack limit during exec To: Andrew Morton Cc: Kees Cook , Linus Torvalds , Michal Hocko , Ben Hutchings , Willy Tarreau , Hugh Dickins , Oleg Nesterov , "Jason A. Donenfeld" , Rik van Riel , Laura Abbott , Greg KH , Andy Lutomirski , Linux-MM , linux-arch , LKML , kernel-hardening@lists.openwall.com List-ID: On Tue, Jan 9, 2018 at 12:23 PM, Kees Cook 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