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 11426C54E94 for ; Tue, 24 Jan 2023 23:08:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 827A66B0074; Tue, 24 Jan 2023 18:08:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B0A16B0075; Tue, 24 Jan 2023 18:08:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 62A106B0078; Tue, 24 Jan 2023 18:08:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 4F5176B0074 for ; Tue, 24 Jan 2023 18:08:47 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 2B87F1C638B for ; Tue, 24 Jan 2023 23:08:47 +0000 (UTC) X-FDA: 80391234294.02.E8A27A7 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf11.hostedemail.com (Postfix) with ESMTP id 789C940009 for ; Tue, 24 Jan 2023 23:08:45 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=lW2Y9CMK; spf=pass (imf11.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674601725; a=rsa-sha256; cv=none; b=PqYY0S4n+yOSlTQvOkGRF6TfgC4PQ+Lxs/+q/l4cLvFu5FJ7ddh1HW6b6SG/ZikAzCvoOy Gfen57gEXkUlJaAWdYFu0dceCdBjCQMZXPhuDcGfPjorf75bfYXNZbAnbXUs/y/7CA7ple OUkaoJnZN4kXntQR3b0wgROrXrRIFQ4= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=lW2Y9CMK; spf=pass (imf11.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674601725; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=IbzbzQ0xciaiyYsjPaDasMlvV/iw0I2Bm7dIPBgXPh4=; b=xgL3H8l858uLae6WpaNB7Zg8cQyMh7iow7yS2F9GHryiv9HY8yqstrgv/d4OTA6GicPWsg dF6F27KNKgY7YwL1+QPPKbfaiFcAGI/e0xBq19uaa/Bi4ugfAbaV9Nuw5sQAB6CkM9B6nB AZsaPeWz8nyfLjAZRurpbRmZ8zN8xsw= 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 89B26613F7; Tue, 24 Jan 2023 23:08:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C7A68C4339C; Tue, 24 Jan 2023 23:08:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1674601724; bh=IbzbzQ0xciaiyYsjPaDasMlvV/iw0I2Bm7dIPBgXPh4=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=lW2Y9CMKwr0f3yBu3MAd11Y5GvI43oUYGwDPlHRFMECuZCbsz3KktpI/NvoqIbzmx 42scFkq0oP3vRnCrL+HmfDa1e6VYFRYrtPRnQOe+Jb0l7WQD5I4igTnWErA71a3hq8 Fhx1d6rxikZEEs88/8ovvCp3FiSfFRmZ3a/CY/CVe/FFnB+SO4LrXQq/qoX7HnjZE2 Neq0VWJcLFsRvTjRK4fk6vrtyBRXCW/LNRByQPL/iEtK4HtzJ9DtW0Yzyr3t8kZbzM W3WPrWB6VDYEUh3KIIp4iKpfAMXV9KHld8741QQMENK1ZX8GxktYhq5GOzq/fP3tAh yOGBEHjAEx6Og== Date: Tue, 24 Jan 2023 15:08:40 -0800 From: Kees Cook To: "Edgecombe, Rick P" , "fweimer@redhat.com" , "david@redhat.com" CC: "bsingharora@gmail.com" , "hpa@zytor.com" , "Syromiatnikov, Eugene" , "peterz@infradead.org" , "rdunlap@infradead.org" , "keescook@chromium.org" , "Eranian, Stephane" , "kirill.shutemov@linux.intel.com" , "dave.hansen@linux.intel.com" , "linux-mm@kvack.org" , "nadav.amit@gmail.com" , "jannh@google.com" , "dethoma@microsoft.com" , "kcc@google.com" , "linux-arch@vger.kernel.org" , "bp@alien8.de" , "andrew.cooper3@citrix.com" , "oleg@redhat.com" , "Yang, Weijiang" , "Lutomirski, Andy" , "hjl.tools@gmail.com" , "jamorris@linux.microsoft.com" , "arnd@arndb.de" , "tglx@linutronix.de" , "Schimpe, Christina" , "mike.kravetz@oracle.com" , "x86@kernel.org" , "linux-doc@vger.kernel.org" , "pavel@ucw.cz" , "rppt@kernel.org" , "john.allen@amd.com" , "mingo@redhat.com" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "linux-api@vger.kernel.org" , "gorcunov@gmail.com" , "akpm@linux-foundation.org" Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_v5_23/39=5D_mm=3A_Don=27t_allo?= =?US-ASCII?Q?w_write_GUPs_to_shadow_stack_memory?= User-Agent: K-9 Mail for Android In-Reply-To: <6adfa0b5c38a9362f819fcc364e02c37d99a7f4a.camel@intel.com> References: <20230119212317.8324-1-rick.p.edgecombe@intel.com> <20230119212317.8324-24-rick.p.edgecombe@intel.com> <87fsc1il73.fsf@oldenburg.str.redhat.com> <6adfa0b5c38a9362f819fcc364e02c37d99a7f4a.camel@intel.com> Message-ID: <5B29D7A0-385A-41E8-AA56-EF726E6906BF@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 789C940009 X-Rspamd-Server: rspam01 X-Stat-Signature: wmokmbhmd14rm8qk564hanud58aug96f X-HE-Tag: 1674601725-640167 X-HE-Meta: U2FsdGVkX18kJbuVfNwUjqnxJej8jbYgEun9UWU3b91LmtvFgSg6lIadOJ7p82cXg+hJrNw+hI4udWfxJJlae1z/EkyRDptVhgUkx/7CNR+dTrasoxfhqhXCbfh+Wrzf6Qmktcvu9jvgWF+Ge0JMqxJSi3LhMH8GBoVhtzgs2nxOPZLADguh8ZfPgQg1SOtCHh0wORd4bz8EO9UtPRD3SWzn1q+Y/xSqll2p/1T630ugCKfM1sD0QVW/bX8sDrIucqRxb3j/mH/Lpp1JWm5g2ePeHpahIrYcr3LUpWopewYKciFXa9Hq/azsYKS+zKqS9DRWUuw7Pyt9bF3x5EPuuMWKcX+C7FotoKr5hTjUaoAqtEhePDLtoUqGz/Yp2nhe29QaR/zeY7i3RckX11fl463WPHqZJTqtz7a+NO9g4x8N/IKyRlsnhbazkPyQAE/XEbKTPtjroSCaK9mOeG/ke8+fIpo6a027NgXgS0/Iy+kK+atb8UJM89MF/CyM30bNK7LRj+0m3s9n3sO2OKHX+AN1dm7UkCvOWDQPpWOBh8Sma6nqMqniT/9He7ozo1089EE+Nq7nVEQO1+JGdVYUnSM6+KE261vo7U1lDJccpiXgr2ZHihDvx2yCD6G09/sWuKiPN9C6tGKrmTN26s542hyr7gjTOqsDjUeb7WntAjac0x+yFYKVHtNKXGDWc9wm1W+5kBlI7TSB7K6YR3dqC+NLWUf9CaAO+TJi7okdYNaWD3d+QX406lN4OIwNJ99aj9IKtFFoKDHy3+G3esa/2OKI0i7pAbOuAcQdSxvtnDQb0w1X85H+bSf6z3QBkUIyArTf4ESwJT9jXWg9OIhjJ8osLfx3D3iDAKTW+wiczNCEU1mb4ltmtByyFWtA4FIX2qQJereO7GHchknJWq7UQHiFPycOm+o65R/5KcuIjePvkGzharLIrFgbWlvag5YP67qxu/+h1HoL9L0vzlL gFRL1yFk 7UK/xLGgxCaN7yXLoII6zIRKC7JwLWCjwWdpl4avSJIf2/xULsvaqn+iJvcJfpeO2jMtNJvOB5vHZKPAJuebu8qzyxv+mvt6+VYWiUq8rO2bvFnC0rC6WbZ9VgZ1gADt8RzPiP8kzgbM96asygu0XCZF8h2weQ9T0KMFttYnbC57cRrar9TvYVgk5HpaKYHjsxrTcKpnG3diijDx6wtzGmnRKAXP2vW92dzbRfEiDw7hbIn/MFTF0dt+mYBkQiCJP/WitR8DepLOsHCDtqUastkiyVyHuAwfADGfzAd3/VskL9rwpwRYwrt+f1QRBjEBxAWTDmS3N57KpOCOcBM10RZz9HSDv03BOE4citc8FX9+dItpbMMzfUFqmE8MgDWV8tIOoPda3XwqvlTuqC2kAB3tgF9yO8al360zRrOL2hO719fBxvuktTT0dKKvO1Gs+MW6gHTe/RwIoDrEclCTzi7z/EqXnpaUdazb6UeZeVfKSlkqt/fSbXMdHaw== 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 January 24, 2023 10:42:28 AM PST, "Edgecombe, Rick P" wrote: >Ping Cristina regarding GDB=2E > >Ping Kees regarding /proc/self/mem=2E > >On Tue, 2023-01-24 at 17:26 +0100, David Hildenbrand wrote: >> > > Isn't it possible to overwrite GOT pointers using the same >> > > vector? >> > > So I think it's merely reflecting the status quo=2E >> >=20 >> > There was some debate on this=2E /proc/self/mem can currently write >> > through read-only memory which protects executable code=2E So should >> > shadow stack get separate rules? Is ROP a worry when you can >> > overwrite >> > executable code? >> >=20 >>=20 >> The question is, if there is reasonable debugging reason to keep it=2E >> I=20 >> assume if a debugger would adjust the ordinary stack, it would have >> to=20 >> adjust the shadow stack as well (oh my =2E=2E=2E)=2E So it sounds reaso= nable >> to=20 >> have it in theory at least =2E=2E=2E not sure when debugger would suppo= rt=20 >> that, but maybe they already do=2E > >GDB support for shadow stack is queued up for whenever the kernel >interface settles=2E I believe it just uses ptrace, and not this proc=2E >But yea ptrace poke will still need to use FOLL_FORCE and be able to >write through shadow stacks=2E I'd prefer to avoid adding more FOLL_FORCE if we can=2E If gdb can do stac= k manipulations through a ptrace interface then let's leave off FOLL_FORCE= =2E -Kees > >>=20 >> > The consensus seemed to lean towards not making special rules for >> > this >> > case, and there was some discussion that /proc/self/mem should >> > maybe be >> > hardened generally=2E >>=20 >> I agree with that=2E It's a debugging mechanism that a process can >> abuse=20 >> to do nasty stuff to its memory that it maybe shouldn't be able to do >> =2E=2E=2E > >Ok=2E --=20 Kees Cook