From patchwork Sat Feb 18 21:14:16 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Edgecombe, Rick P" X-Patchwork-Id: 13145663 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 EFBCEC636CC for ; Sat, 18 Feb 2023 21:16:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5825C280015; Sat, 18 Feb 2023 16:16:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E26A280016; Sat, 18 Feb 2023 16:16:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0259F280015; Sat, 18 Feb 2023 16:16:21 -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 CDF4A280015 for ; Sat, 18 Feb 2023 16:16:21 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B41571601CD for ; Sat, 18 Feb 2023 21:16:21 +0000 (UTC) X-FDA: 80481670962.27.A933075 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf16.hostedemail.com (Postfix) with ESMTP id D9292180007 for ; Sat, 18 Feb 2023 21:16:19 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=cqKAMcsN; spf=pass (imf16.hostedemail.com: domain of rick.p.edgecombe@intel.com designates 192.55.52.43 as permitted sender) smtp.mailfrom=rick.p.edgecombe@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676754980; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references:dkim-signature; bh=W34Awsk7ObJ3JdP2fcXDLIDAtaSphGEmGZ3iOjCGOHY=; b=ReV1R9zFyBh2dU4IjVGQDdoKvVHvqriKorujg3jXBu1g7XJeDHuk6M4zhZzVJ8RdPj5Vd7 bIpoJ7nG/Zep1Xrn0NWtKa6+UKRjBoc+sCR0MKehg8plHlJ8V+yjRO05MYCzMEuYrfUGEW D+wabDg62BdMFWMLMdvunqJUtspb1Jw= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=cqKAMcsN; spf=pass (imf16.hostedemail.com: domain of rick.p.edgecombe@intel.com designates 192.55.52.43 as permitted sender) smtp.mailfrom=rick.p.edgecombe@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676754980; a=rsa-sha256; cv=none; b=6nxn9FbnMFi+JE6DWWHvVIoT4rKmnzmalxUQLn3LxDjKNK9Fm7FvSR7uxlRmO8v1mL5JjZ qb3de78W+moGSUyKFSd1bjorcBbN4XN/ri7WBxzkQU4FZl/kOoMEz9pIP2vGvZNSYoQd2J nUJHGaKKPi+HNltQlEYfvM4/s7pv+eU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1676754980; x=1708290980; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=ECFpkrFmLdwFWEoO9V0RJS5m7s8m94UVjRDo+XGZ7qk=; b=cqKAMcsN0dx1D7XgrCoSGK+qi/JdEbMwVtIsL1ALyoSW/26V8nGuvRmM 283ZJtc8l7tLZSOa+DKcXZdlKGEKkhUgmSaD7CXA5HrlECiIzerTcSURp 9wM9HnOWYgenIGHJeKKkArKzKPFa+KDrJrUGZKE2Lizrj2588fgz7LhTv t+jhfXt4RPRY8C+F52v8hZExNwjXFgX3oPt/YFg3/A2IdOIlWMfpXsOo2 OoDUyiHXs4uufBVnDIZHImdRsh+K7DfquMZuVYB2Ke1UOE37SFrhrxAj+ GW01LA0OjzZ42QuTJSSr6pUivWEY3IXYxZddxezuuRg/qt3rXeP5GEBxk A==; X-IronPort-AV: E=McAfee;i="6500,9779,10625"; a="418427612" X-IronPort-AV: E=Sophos;i="5.97,309,1669104000"; d="scan'208";a="418427612" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2023 13:16:16 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10625"; a="664241685" X-IronPort-AV: E=Sophos;i="5.97,309,1669104000"; d="scan'208";a="664241685" Received: from adityava-mobl1.amr.corp.intel.com (HELO rpedgeco-desk.amr.corp.intel.com) ([10.209.80.223]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2023 13:16:15 -0800 From: Rick Edgecombe To: x86@kernel.org, "H . Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H . J . Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , Weijiang Yang , "Kirill A . Shutemov" , John Allen , kcc@google.com, eranian@google.com, rppt@kernel.org, jamorris@linux.microsoft.com, dethoma@microsoft.com, akpm@linux-foundation.org, Andrew.Cooper3@citrix.com, christina.schimpe@intel.com, david@redhat.com, debug@rivosinc.com Cc: rick.p.edgecombe@intel.com Subject: [PATCH v6 24/41] mm: Don't allow write GUPs to shadow stack memory Date: Sat, 18 Feb 2023 13:14:16 -0800 Message-Id: <20230218211433.26859-25-rick.p.edgecombe@intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20230218211433.26859-1-rick.p.edgecombe@intel.com> References: <20230218211433.26859-1-rick.p.edgecombe@intel.com> X-Rspamd-Queue-Id: D9292180007 X-Stat-Signature: y5g8orpf5efs1p1nceeq8bjhdqjokr6m X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1676754979-135475 X-HE-Meta: U2FsdGVkX19ErAQ3sUR5PmFD9HF/LAzKUnZzs+WQQ0JkWdvCeqqs0JSLzfatBv0917ayW+iQa2q88KQztNcSB/A98fB3RRuohtV64+UiF7TUMBMmFpgQzGFqgdwRhOQ8AArHM8NTmprrZx8MZAW51ykW480MT3+mXigJvpukA2Qfr2zVPrw7lG/+9w5u3UmsJUIM7WxKu1g5OYSZFIHWzBFHwKognm30qX7OEmi8QmYTcR8YN7LlC9A1XEafF9T38S+r1ysfVOdLUnXN0rbBa9mjSt5hnlNKtuVoss3tvcGMKFqtkfgz8bvneggpd0WkvSviokgn3d08k5dMBeyoZA+45T5W/k+qn7Q52PjetGOxpWDkpKyRLSJHkbtkXO+7DFkthzTaNwd+NbfD/IipD/dogYzV2foArSxuUX+dBX0U7fsCJJmA2cyuev5N8uMUVpUUkTv+itoZnoFCFG4qzuqX8/n9dQcJ6utYKJkVQTW6gtYV1srX/9jIDrqmsn4/mmNtXWS7y/DXb5hJQttm8n090YQ+jnzfWezfX9/F/z7bX6dz4/IE5rqrxasT0nwcDMUJY0d//Mh/F3F6Fhwho1vE0ASh5CgMEnetZ+S6tFu2SisdaMeaAW4QdlBHhDDWRjyYMJ/i+HgVUVJtVAtUlEKln3nAB6KfB62vAkfYg5Ri6WPQ/lq0wfOrHzOd8Px2m3LQf1nDDWaqM56zzaLW86l4DTJzy9JRjVFX4ZKBL8rlSrR/6pv4pKSQht8mzpSk8h8LS/rVY+ktCf5qRjEG8PYkkwtmhOjLUepPogfwx5ndrDP4WEPd1/0eUGYVWEzI3VeTYqizT8JXIdu3CHPRVLQbtPoK57mTyVLjE4rnMWjENAVVTwigThheYpXvOSOISGEaNuA1e7suwn6jEhBUG2XpRp9yvUyGxLGH1eSvMaPGnwPwvllurx66zYF9Ph2BUZZy3oO7LtBAPWKJoVe ILvlegUv b/yCe/FrskhDfJk1yES1SHYgjlkQCF3iO8FNPbmRP5XMsv8CywoPstbsE+QRIzELocg+kAFd8avY9kv1tawVd0LyaUFEgoz6XXQkUxoe+drhdAwYwd3LUc/N7gx49i3jd8e/N7uqYR93r4yeE8oGeSuxzCbNRK99YZeCstNO5Lg6aqp12sIRdAzwl1STK0rgR4i1v4xGb9mt0qaNBHWzaaqo+Mc1tECVDkGqxzEKjJZ1Dtup6jYaulMX8/n3BWzAT38ioXOi5AgODzYIUXt1Ad+iE9C+uFV79udCL 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: The x86 Control-flow Enforcement Technology (CET) feature includes a new type of memory called shadow stack. This shadow stack memory has some unusual properties, which requires some core mm changes to function properly. Shadow stack memory is writable only in very specific, controlled ways. However, since it is writable, the kernel treats it as such. As a result there remain many ways for userspace to trigger the kernel to write to shadow stack's via get_user_pages(, FOLL_WRITE) operations. To make this a little less exposed, block writable GUPs for shadow stack VMAs. Still allow FOLL_FORCE to write through shadow stack protections, as it does for read-only protections. Reviewed-by: Kees Cook Tested-by: Pengfei Xu Tested-by: John Allen Signed-off-by: Rick Edgecombe Acked-by: David Hildenbrand --- v3: - Add comment in __pte_access_permitted() (Dave) - Remove unneeded shadow stack specific check in __pte_access_permitted() (Jann) --- arch/x86/include/asm/pgtable.h | 5 +++++ mm/gup.c | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h index 6b7106457bfb..20d0df494269 100644 --- a/arch/x86/include/asm/pgtable.h +++ b/arch/x86/include/asm/pgtable.h @@ -1641,6 +1641,11 @@ static inline bool __pte_access_permitted(unsigned long pteval, bool write) { unsigned long need_pte_bits = _PAGE_PRESENT|_PAGE_USER; + /* + * Write=0,Dirty=1 PTEs are shadow stack, which the kernel + * shouldn't generally allow access to, but since they + * are already Write=0, the below logic covers both cases. + */ if (write) need_pte_bits |= _PAGE_RW; diff --git a/mm/gup.c b/mm/gup.c index f45a3a5be53a..bfd33d9edb89 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -982,7 +982,7 @@ static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags) return -EFAULT; if (write) { - if (!(vm_flags & VM_WRITE)) { + if (!(vm_flags & VM_WRITE) || (vm_flags & VM_SHADOW_STACK)) { if (!(gup_flags & FOLL_FORCE)) return -EFAULT; /* hugetlb does not support FOLL_FORCE|FOLL_WRITE. */