From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Cyrus-Session-Id: sloti22d1t05-747567-1516410766-2-18345455113163807417 X-Sieve: CMU Sieve 3.0 X-Spam-known-sender: no X-Spam-score: 0.0 X-Spam-hits: BAYES_00 -1.9, RCVD_IN_DNSWL_NONE -0.0001, RCVD_IN_MSPIKE_H3 -0.01, RCVD_IN_MSPIKE_WL -0.01, SPF_PASS -0.001, LANGUAGES en, BAYES_USED global, SA_VERSION 3.4.0 X-Spam-source: IP='209.85.213.195', Host='mail-yb0-f195.google.com', Country='US', FromHeader='net', MailFrom='net' X-Spam-charsets: plain='us-ascii' X-Resolved-to: greg@kroah.com X-Delivered-to: greg@kroah.com X-Mail-from: dave@nullcore.net ARC-Seal: i=1; a=rsa-sha256; cv=none; d=messagingengine.com; s=arctest; t=1516410765; b=vNxgk9apZkqgNchBINSWX6lvD5fek40wK9cAsoGQ029X1Jk iEoX8x7pcbfRtAkG0PovHEFbX+lCTpb1rWBVOJwlbEg0W1N6tMtJY4VtE8Z0hDmx JcbmTIketbKOZSUZvSkd3EhpAjakAuGMck3oH1xb7m+uCYGvl/3P4KjoigQ4XNWQ BlzeERDEMUYP4+59bwiwkAzFT6dehk2jbQkagPxYF7EuSNYDb2CbeGw7+TUZOodq 8ru/NyaKzqDHnWHzD/bh8yJ70fZaMjnssydclsR19JmD7sJ9RSggaSISVkrNP+7/ PeQMrxHhThULD/no1ALndugd/6g4sHX8bJcHoLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=arctest; t=1516410765; bh=LPcz2at2ujd4SdsX2K/+ MruY+CwxH/YB7asG+/CKSyI=; b=pB5wXKtzyp+6dWh2eNlkmHki1eISLB5KygCG IOCCXiMdaY1zuVGFvUOVnOdQwvdyHc4JU/JnXTBb9N7F3g18zZskpeQlLpcBrG0z PTU9iU5KQqK1TWg6Bb5OHvMos66m8n1zUhRwAgRoJeSyqckxlP5SPqbqr7P9CP+h B1XBy7gRS2px4Pk+Zc3l3C8Ds/slbefWrumtf6lXS7wYqTRhaOrmoSIhz2C5I5XG aeQXuwzTW/1lGYdwzGSAc5lPC6Aalm2LWwEXeAFEiDW4iiBwGhSqZEMnP+iaH1FP 0ITB9Wy82Eqs2fxhJnqOPZs8khLO7/gnsLxM7fvHHJrXwVgY5g== ARC-Authentication-Results: i=1; mx2.messagingengine.com; arc=none (no signatures found); dkim=pass (2048-bit rsa key sha256) header.d=nullcore-net.20150623.gappssmtp.com header.i=@nullcore-net.20150623.gappssmtp.com header.b=WfVQWISR x-bits=2048 x-keytype=rsa x-algorithm=sha256 x-selector=20150623; dmarc=none (p=none,d=none) header.from=nullcore.net; iprev=pass policy.iprev=209.85.213.195 (mail-yb0-f195.google.com); spf=pass smtp.mailfrom=dave@nullcore.net smtp.helo=mail-yb0-f195.google.com; x-aligned-from=pass; x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=iW1X+V6u; x-ptr=pass x-ptr-helo=mail-yb0-f195.google.com x-ptr-lookup=mail-yb0-f195.google.com; x-return-mx=pass smtp.domain=nullcore.net smtp.result=pass smtp_is_org_domain=yes header.domain=nullcore.net 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: mx2.messagingengine.com; arc=none (no signatures found); dkim=pass (2048-bit rsa key sha256) header.d=nullcore-net.20150623.gappssmtp.com header.i=@nullcore-net.20150623.gappssmtp.com header.b=WfVQWISR x-bits=2048 x-keytype=rsa x-algorithm=sha256 x-selector=20150623; dmarc=none (p=none,d=none) header.from=nullcore.net; iprev=pass policy.iprev=209.85.213.195 (mail-yb0-f195.google.com); spf=pass smtp.mailfrom=dave@nullcore.net smtp.helo=mail-yb0-f195.google.com; x-aligned-from=pass; x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=iW1X+V6u; x-ptr=pass x-ptr-helo=mail-yb0-f195.google.com x-ptr-lookup=mail-yb0-f195.google.com; x-return-mx=pass smtp.domain=nullcore.net smtp.result=pass smtp_is_org_domain=yes header.domain=nullcore.net 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: AH8x226ZrPUwAwBoCfmv8G5jssQWvEI0ffCdw6NnjwEbaja6C+v99l0i8oBWHstrpN7UqSHsaRVHCw== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: [kernel-hardening] Re: [PATCH 0/3] exec: Pin stack limit during exec From: David Windsor X-Mailer: iPhone Mail (15C153) In-Reply-To: Date: Fri, 19 Jan 2018 20:12:40 -0500 Cc: Andrew Morton , 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-Transfer-Encoding: quoted-printable Message-Id: <8BCDD560-66F5-4CF7-97DD-E2E5BE1D13F4@nullcore.net> References: <1515529383-35695-1-git-send-email-keescook@chromium.org> To: Kees Cook X-getmail-retrieved-from-mailbox: INBOX X-Mailing-List: linux-kernel@vger.kernel.org List-ID: I have some spare cycles; is there any more relevant information outside of t= his thread? Thanks, David > On Jan 19, 2018, at 5:49 PM, Kees Cook wrote: >=20 >> 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. >=20 > 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... >=20 > Thanks! >=20 > -Kees >=20 >> [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?" >=20 > --=20 > Kees Cook > Pixel Security