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 BFD70C27C76 for ; Wed, 25 Jan 2023 15:23:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 26E686B0071; Wed, 25 Jan 2023 10:23:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 21F3F6B0072; Wed, 25 Jan 2023 10:23:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E7086B0073; Wed, 25 Jan 2023 10:23:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id F30736B0071 for ; Wed, 25 Jan 2023 10:23:36 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 59DA7C0D2C for ; Wed, 25 Jan 2023 15:23:35 +0000 (UTC) X-FDA: 80393690790.06.B878C24 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf16.hostedemail.com (Postfix) with ESMTP id 710BD18001C for ; Wed, 25 Jan 2023 15:23:33 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="m+9tXk/D"; spf=pass (imf16.hostedemail.com: domain of kees@kernel.org designates 145.40.68.75 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=1674660213; 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=n0tElQWhc562jr5djK4tbNXbksESM0fB5VT7n9Ly9wI=; b=klx/ihZMIhWgaMcwTOHl6cjpiTt5hl9VkERJl6Vn5BKz1uQvA5TDTW0LOQawX6QlLWAYsA 92mOTcXXVN2nzIXKimMTLg40srvwXnr+PXda7pPhmb8yIFl6VUi0oGFf7K5Ob2Zxi+ds/B cj4RB0F2TWr7g5+FDZ67oLuqrBX1XNs= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="m+9tXk/D"; spf=pass (imf16.hostedemail.com: domain of kees@kernel.org designates 145.40.68.75 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=1674660213; a=rsa-sha256; cv=none; b=4jjwDcnO3WSQI16EzB8VfvsZh8ZFeLVemFkHfqnD/SYJkTipUKK4bm5FdZhTY92KnCLTIH P2jBei5v4MCEcU7tUJEm4HDJgwJLJ1BqyVNkTqYfwGG3WLFMvKL1zptgmV4CxbNXHGBv5X n46GhjnXIvx/Snv6E0tesgjURXeIH8E= 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 ams.source.kernel.org (Postfix) with ESMTPS id AC81AB81A90; Wed, 25 Jan 2023 15:23:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2951BC433D2; Wed, 25 Jan 2023 15:23:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1674660210; bh=n0tElQWhc562jr5djK4tbNXbksESM0fB5VT7n9Ly9wI=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=m+9tXk/DTy7ifoyPec9EcyhpTAAqJrxu4qHW6Q2bg0O6TTABR7F5ox3b4OfXin6md 57FM+xKSno9XHmivVCSUxotkFpmge5Vt/izlLctl/58yz+Naixw6uchInoU3DKMQZ2 I566mi60QW2bgUkCakrEs4Rnyb8JbKDeilhm7x+yZsIr6hVirawYH/rKwh10/53Qx/ /PC9wC8iiiwJP59J+tx7q4VA6yPYCRhtWyNHXtI+EN5Yn3wYJVI059L/kbo8cCp9B4 0okvWfIz/Mx9sD/QwKVJTzeyqaCgyLcKp4qQK7NL3VYNZ2ARBRAXoIKMO9P8galWAg SMd/rfHjqC30Q== Date: Wed, 25 Jan 2023 07:23:27 -0800 From: Kees Cook To: David Hildenbrand , "Edgecombe, Rick P" , "fweimer@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" , "john.allen@amd.com" , "rppt@kernel.org" , "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: <716d9e97-b08f-eb0f-101a-be6eaf36f184@redhat.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> <5B29D7A0-385A-41E8-AA56-EF726E6906BF@kernel.org> <19ff6ea3b96d027defb548fb6b7f89de17905a4b.camel@intel.com> <716d9e97-b08f-eb0f-101a-be6eaf36f184@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: p96e1ubi5znjtoc1yxeuhjrtn9xidm7k X-Rspamd-Queue-Id: 710BD18001C X-HE-Tag: 1674660213-987564 X-HE-Meta: U2FsdGVkX1/nsWFgclQ9blwJgrz9FNXvtGn0SAnpzUeLVLyJZH2Lrp3ussT4wqP5WaOC9uCoawAUhJdRQc70jsTZkIJ0SJWzWczZowij7L0ERLhmm8M9cViD3J6kTFKSYkFdeI165Ez3ZUfLNZ08NKjKMFTLWen8werlUo0JJWl/DRaOFxDhJ/qG7It21h4VdSDZQ0zDJKOZfMf1xEssgnudvgrWf4HZXWwkt0nhfPcR49sqWKtmTYP2+CduvupqeJtB2E0LkVRVtL+EgMFwOkdnbneOylLEgOW5zS71MxRSLWudvY16O1MDnEc+RHxQ9Ewhak60s0yvVNCKkUqfWiTNyJv23vLhM0fTIpJACzLxUcKjghDVTfX+1NMagW5CXC5X5fXSYKf3/Iie+R3mne0rUBqlKS+1m0tzMvbq9gE3Zr+PXJVToivQ8HNkk9RwVHwKEnv0NA4JKfCgD+Um4Aio4fYp89NLASSvxpaolnGnKpTBacjNR/6rYvgcDl4C6nZ71ZgiqW5QFilrd70FnCbjstXEXquV1bCe7eeAk85YEs7f/40rLsm5gA6ZDV9Fb6sxmuVt12x2zOeq3IgonfCf3tuWLLLXtljaraOt7VyhvKW2GzihA+slSAC0ZilX3nn2tI/31abgl8q1o6z0Tq+xueiyJzULinQh8uzK8wziTsMS9DO60AQdslKvS6B52d+ei+7+O2WHbdbOvWNC06vgHTb0zOb6CXerYVqBXBkhh82pRzVrwFCEsy7vXHcOCbQJdRzAHBiBAkIxirUC0/bBoCsMTqRTe5aqTvFt1wcQw2yKhesvQwrvUp+GbtXUezY+B7BSHmJF3rAdu+4lSzRb8E3tAt4sgtbda9zQ2J7IiasV9GA8ITT3ia68MFLOdFCBdjcJnW+fGYYZP9JTsWTaOfe7o2aKxv4u6ru+0ialrvdJjiHpTmMJJrHCJE0nt+6tCwFUv8N+ofI7Tgk k/Cz3YOF RO6ueuu9tDSpWHVusJl82pmrmeFXnqUcdsutOYLf209cyEp4jmx2++7qfXK7XUKgfhqrQtfxlfn7K9hv28AJf+1ugGZE7Y2dr1roe3epZf2K5X7zqERc1d7hxA1pgXPkp114gtwQi3QpIlxWGYexeHBQ2TbGB+Og6Up3xLVh0rVZJnV1k0WP4VFGBQ62SjjX8IOd6DoNo+nh/6vF6ztyuA0SsjdaMkqNWNV4u16xH/WR0NCFvh0RsumGLOvMv2rSKGRBpqYAzQurBi1T3KO0QAsWIaIhyOU6dCDkB2Wgx20Z//2otWuX+qTNH47EliQrbkBbFZ/v/+qgM0Co9QdZk2pKtTuGLh8d8KLQd4IfM7Gnq4+pbX9xSoXCCZMC1KHeLsfug74NwXdkfNCDKU33FGC8aN0Y2k8HXxHPaGZl5nFyaRGxDWasVi0wGiVLTWwWrQ/ji3BaGOz06B43mv976zufn5l6gF0uXuc2y192kO9HkWjJjuVTp7UA5CA== 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 25, 2023 1:29:20 AM PST, David Hildenbrand = wrote: >On 25=2E01=2E23 00:41, Edgecombe, Rick P wrote: >> On Tue, 2023-01-24 at 15:08 -0800, Kees Cook wrote: >>>> 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 >>>=20 >>> I'd prefer to avoid adding more FOLL_FORCE if we can=2E If gdb can do >>> stack manipulations through a ptrace interface then let's leave off >>> FOLL_FORCE=2E >>=20 >> Ptrace and /proc/self/mem both use FOLL_FORCE=2E I think ptrace will >> always need it or something like it for debugging=2E >>=20 >> To jog your memory, this series doesn't change what uses FOLL_FORCE=2E = It >> just sets the shadow stack rules to be the same as read-only memory=2E = So >> even though shadow stack memory is sort of writable, it's a bit more >> locked down and FOLL_FORCE is required to write to it with GUP=2E >>=20 >> If we just remove FOLL_FORCE from /proc/self/mem, something will >> probably break right? How do we do this? Some sort of opt-in? > >I don't think removing that is an option=2E It's another debug interface = that has been allowing such access for ever =2E=2E=2E > >Blocking /proc/self/mem access completely for selected processes might be= the better alternative=2E > Yeah, this would be nice=2E Kind of like being undumpable or no_new_privs= =2E --=20 Kees Cook