From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id EE773C433EF for ; Sat, 26 Feb 2022 01:47:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 81AAC8D0003; Fri, 25 Feb 2022 20:47:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7CA2A8D0001; Fri, 25 Feb 2022 20:47:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B9C18D0003; Fri, 25 Feb 2022 20:47:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0086.hostedemail.com [216.40.44.86]) by kanga.kvack.org (Postfix) with ESMTP id 58A428D0001 for ; Fri, 25 Feb 2022 20:47:00 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 0669C9A265 for ; Sat, 26 Feb 2022 01:47:00 +0000 (UTC) X-FDA: 79183242600.22.0E509D8 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf31.hostedemail.com (Postfix) with ESMTP id 94E2B20007 for ; Sat, 26 Feb 2022 01:46:59 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id F160961E19; Sat, 26 Feb 2022 01:46:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 15CEAC340E7; Sat, 26 Feb 2022 01:46:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1645840018; bh=XOAz6ET5rcJ82aoCqycGO2AwFyZKFec2j0t25J+3Gis=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=DAuSj1O8gIXKuuNgtA6wwSA7e1XT42Y1zUEM/zWv6pYOK4OrY8b61jprjfdjl5+3W 1unXrifjjxipUd0BKkzb2hCnBG1pEe4hNVEdBMU88ZjvWvoqwZE7NAM0Htz5QN95zY T8fZ2atZmt7vvsopoFQ3JkrSBJ2fp0aJHc6rT3tg= Date: Fri, 25 Feb 2022 17:46:57 -0800 From: Andrew Morton To: Kees Cook Cc: Matthew Wilcox , Josh Poimboeuf , linux-mm@kvack.org, Muhammad Usama Anjum , David Laight , linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH v3] usercopy: Check valid lifetime via stack depth Message-Id: <20220225174657.9e1af8ec59ce8dbf223f84c5@linux-foundation.org> In-Reply-To: <202202251728.1634F405@keescook> References: <20220225173345.3358109-1-keescook@chromium.org> <20220225160157.680ecdea21ce81183059bb63@linux-foundation.org> <202202251728.1634F405@keescook> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 94E2B20007 X-Stat-Signature: za13tt98mjzg8jgmtkp96agaaiqogsmn X-Rspam-User: Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=DAuSj1O8; spf=pass (imf31.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspamd-Server: rspam07 X-HE-Tag: 1645840019-268670 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, 25 Feb 2022 17:35:49 -0800 Kees Cook wrote: > On Fri, Feb 25, 2022 at 04:01:57PM -0800, Andrew Morton wrote: > > On Fri, 25 Feb 2022 09:33:45 -0800 Kees Cook wrote: > > > > > Under CONFIG_HARDENED_USERCOPY=y, when exact stack frame boundary checking > > > is not available (i.e. everything except x86 with FRAME_POINTER), check > > > a stack object as being at least "current depth valid", in the sense > > > that any object within the stack region but not between start-of-stack > > > and current_stack_pointer should be considered unavailable (i.e. its > > > lifetime is from a call no longer present on the stack). > > > > > > Introduce ARCH_HAS_CURRENT_STACK_POINTER to track which architectures > > > have actually implemented the common global register alias. > > > > > > Additionally report usercopy bounds checking failures with an offset > > > from current_stack_pointer, which may assist with diagnosing failures. > > > > > > The LKDTM USERCOPY_STACK_FRAME_TO and USERCOPY_STACK_FRAME_FROM tests > > > (once slightly adjusted in a separate patch) will pass again with > > > this fixed. > > > > Again, what does this actually do? > > [answers] > OK, thanks. I think a new changelog is warranted? What's your preferred path for upstreaming this change?