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 11B11C27C76 for ; Wed, 25 Jan 2023 09:29:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 597F46B0071; Wed, 25 Jan 2023 04:29:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5471C6B0072; Wed, 25 Jan 2023 04:29:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 399F96B0073; Wed, 25 Jan 2023 04:29:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 2A8B66B0071 for ; Wed, 25 Jan 2023 04:29:31 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id DA4A5AB0B9 for ; Wed, 25 Jan 2023 09:29:30 +0000 (UTC) X-FDA: 80392798500.01.6310C30 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf09.hostedemail.com (Postfix) with ESMTP id A25F3140003 for ; Wed, 25 Jan 2023 09:29:28 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=H2d58l9R; spf=pass (imf09.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674638968; 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=TjE3MFK73jMeqX5iFxpax2sxTvtsTUXIevN9S/ssTM8=; b=QWBOWWDWoCZ0PZQwKuM78ugEWhON/83juwWtGHrGifMozd7zHcZH3cskGBrktFFQFGpCkR ZYveR6rvAVO7Pgk7lijRi7KuhSwet4ei2kQSlHzwMZact2+QQloVNiPGkadb+dBhn3bld0 EG6JmOZ2rQMntcViSpSaTDGMHqiIclU= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=H2d58l9R; spf=pass (imf09.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674638968; a=rsa-sha256; cv=none; b=PO+wxtYYwt6kyauIClPOboyK/Wt79c+PM8s+1WzuQxTf5u36HEOLWV3bizajT9wG6nPG+S coYj+uBZlUH8xUBn3RWyLfwzAr0ya1LBiYkARLm4YNT5vz14KIDgxUV1qMqv8cSQeMqaD/ x6J2NTvkVfn/GQ1Pw0nvEGHGBbUMxrQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674638968; h=from:from: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; bh=TjE3MFK73jMeqX5iFxpax2sxTvtsTUXIevN9S/ssTM8=; b=H2d58l9RkoM1F1m1hFxiiEft0rJbaw7bMnjKx91XbTY6K/sb50gCiLJ5RyOMjxhuJZf+st FDrprGP/gf9QzARf9Rgmmm+nkoThJo7pBIIlWY4SKsO7z8bscdQ0vTRTu1fWBbOXD/pNdN ZhydoI1VK96hYT4bmbCTk1lCzbpyfrs= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-664-kZfzlmZBPGKqkI1AzAlf5w-1; Wed, 25 Jan 2023 04:29:26 -0500 X-MC-Unique: kZfzlmZBPGKqkI1AzAlf5w-1 Received: by mail-wm1-f71.google.com with SMTP id h9-20020a1ccc09000000b003db1c488826so804852wmb.3 for ; Wed, 25 Jan 2023 01:29:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TjE3MFK73jMeqX5iFxpax2sxTvtsTUXIevN9S/ssTM8=; b=KgHCdzK7HBaWNxYK4f0fc4IHIeFcL6AQ3yu/8DHtxaSkyknWv36vjZO+U1dvVbXMtb 4syx+/ZG3B9gOUm30rDuPDIP/T2tBztemJKcgvEQdU2IspEgUrHDoP7L0iihUjZfHYl3 mnXSjvSTmbLxz4hNeikp77XYZSkbKqIwqNFFrTUZXZMS2p5e+xUFHXFDZ65kLaOHjU0V nxOs0RzDxHbtFjlKdxVilaExCYLkit+dq6FV2CL25wSHhNi9LNsLYbl5sVb7bozFSCRK RZ7r4uy2PSxyr/QjDfWGmaqe41otk9q0XBaLPGQw+xBWA1UW2ypPPZar4cK/RiUGTqfj N/DQ== X-Gm-Message-State: AFqh2kqrQJ6A/J3NPnc7ZRAdWrr5fgQMR5+WcR0f/+dqWBOhn9jOQ8Gn vkgCUPysxZtLaQhMuUB0kweB90Ux9OX7tXQ31eCEEW3wID+4ftYdWndrnQg1WJh9wuFdIYZ+Oh/ /erD3lBfNrgY= X-Received: by 2002:adf:fb86:0:b0:2b6:7876:3cd4 with SMTP id a6-20020adffb86000000b002b678763cd4mr25258772wrr.16.1674638963423; Wed, 25 Jan 2023 01:29:23 -0800 (PST) X-Google-Smtp-Source: AMrXdXsLivmPABRiZvHHfGmnyR69nY5+HViCF4rvX0glv7Y5M6gJXrX848D3l9+TwkCsYm87blrEGw== X-Received: by 2002:adf:fb86:0:b0:2b6:7876:3cd4 with SMTP id a6-20020adffb86000000b002b678763cd4mr25258727wrr.16.1674638963093; Wed, 25 Jan 2023 01:29:23 -0800 (PST) Received: from ?IPV6:2003:cb:c705:4c00:486:38e2:8ff8:a135? (p200300cbc7054c00048638e28ff8a135.dip0.t-ipconnect.de. [2003:cb:c705:4c00:486:38e2:8ff8:a135]) by smtp.gmail.com with ESMTPSA id d9-20020adff2c9000000b002be34f87a34sm4166170wrp.1.2023.01.25.01.29.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Jan 2023 01:29:22 -0800 (PST) Message-ID: <716d9e97-b08f-eb0f-101a-be6eaf36f184@redhat.com> Date: Wed, 25 Jan 2023 10:29:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH v5 23/39] mm: Don't allow write GUPs to shadow stack memory To: "Edgecombe, Rick P" , "fweimer@redhat.com" , "kees@kernel.org" 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" 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> From: David Hildenbrand Organization: Red Hat In-Reply-To: <19ff6ea3b96d027defb548fb6b7f89de17905a4b.camel@intel.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: cdxfget7bcffac5ziq6awau3ifn1jk6z X-Rspam-User: X-Rspamd-Queue-Id: A25F3140003 X-Rspamd-Server: rspam06 X-HE-Tag: 1674638968-424711 X-HE-Meta: U2FsdGVkX1+71gEiyGpdZBa4WRv5JgvV707x9EH0Bl8ij8g5yivF/BXZIOhDZ0vvCNFTn2uxwL0mplW1pbK2rdTQFJg6JwKOlHn1N+uUdctOY2nMSnszk4NRQPxIdfUKvmuxv/3rL0zBGE300vyGgA0RVSAPE7f2tpjTt4w2HZJpuC5+MMUIB9wQ0M8hS7nPYNLPD70OKOcUPPhOiYM8TWL78Ww4EZmCZbzN6fvEsNcF1Y6K3N7p5wj1OK+z2Yp8e7uw+MFf9P2bnYCOLPrdhgklmwUIKkwrdQl5dk6tSYnIYZlO68jZux38ETkrTPH93YG5/wFHRDRwHe92rbN3opfdAP9p4TpHhT0qM53vIb2UDO7EAK8M+keFvUu9LfWUbGwiB7uIYfEHC6V3wpr41jmVtBAgXA395ZLiUAp4zdIjGY8Jvg4iHRaCttVLliXWCDYH0jclKMSMtWn2gypR6iJw/t7J832+WBp3VHL/SDqmidlLPKbCJBOgtDU0Is0Hl8Rs/m/hfwELS1+dWsWGT14ztGpMRLBSLukdFfCQConUUSMF1egk2hVN5FkS7B7ZUoqORnd1yA0SSHHYTgaDnEFBV1uKjS10skzp3C3pT4C6jwItGHjdMV1bAMI4WZPXsFOEruSsiofdZLmUqAXPXl2W/JbcHufXuWD/dlLUbo0unWSfYXtY+FsxvU9E1j2Tt5o3l5ijgS3cFCjr1GRqZKGBcT1EyxlAeNfEatiAo/iNS1MqWvOgUS86g8KGOqsXqhJKFimROSkgdSTyHT9mOWuppTTKBCmaO/KS0nxcvnaMOvANYmM3o8xSX7Pz+83SmTJpCin9Pt5ojWwIwaVBNN1Bbf8KZVFiWYntX2BsAZQPGcud/AM8N5Tcx+GYpj8e4wp2hl7S20koNKR/MYO2IePzefMxUPHXmfSnBD4W5AyHG4E5/Q9c/PS1yQC7Wa3lnrl0cxweAC4EW+DCTb2 /9EWypgc 3v3K2jK0bviuZnjE7CDTKiSvFd4sHHnuXPkz3nKeiblf0cXraCihiOnhOxgZj9Lg8GVWPR2WyYrIQRmaj8U2pVOcPNjwSRHrXCQHZbBEyJJg+A4nn3252/iRrxVTIjSRjs3sqdzspm7gEIzSIaXrBJ5KqN0Tw0ApYaqUi9r8vols6Md2TWZv4TNHPhjjLepWQ9FHOeWR8xgZE+cmVtnFmj4QTBOFGjk+fvpD+oqNbEB7JhZQTmcEOExcPs6uUq2y417sJxo2jxS1KN9KU4G+N72UxpcXzSzb1ALYF3CCqLGUkbBJINSNuzj5O2RuyD/mXpsTFqZILpmF/dlyJ+FkcfoPN8Nc1FVtNrU/rgCsrWVsmkXTkn6F5ZYkv2qRMZy29Urmvm2N3W4uprCStkym8rbwv9zrke7o0uTEHkyGQjHeZmPB7iMPFfKC/LDo5Pf23k5buslxvzbQtm84QhY/5qdQq8wWgj8u13j2Pa6sXxmaXr+R6iP4XQzC+rwYDfZgX6tPa 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 25.01.23 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. I believe it just uses ptrace, and not this >>> proc. >>> But yea ptrace poke will still need to use FOLL_FORCE and be able >>> to >>> write through shadow stacks. >> >> I'd prefer to avoid adding more FOLL_FORCE if we can. If gdb can do >> stack manipulations through a ptrace interface then let's leave off >> FOLL_FORCE. > > Ptrace and /proc/self/mem both use FOLL_FORCE. I think ptrace will > always need it or something like it for debugging. > > To jog your memory, this series doesn't change what uses FOLL_FORCE. It > just sets the shadow stack rules to be the same as read-only memory. 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. > > 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. It's another debug interface that has been allowing such access for ever ... Blocking /proc/self/mem access completely for selected processes might be the better alternative. -- Thanks, David / dhildenb