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 8F03DC7EE43 for ; Mon, 27 Feb 2023 22:32:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0A3906B0099; Mon, 27 Feb 2023 17:31:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 07C7C6B009A; Mon, 27 Feb 2023 17:31:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DE8B66B009C; Mon, 27 Feb 2023 17:31:51 -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 CE0FD6B0099 for ; Mon, 27 Feb 2023 17:31:51 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id A66B7806D6 for ; Mon, 27 Feb 2023 22:31:51 +0000 (UTC) X-FDA: 80514520422.04.E0959BB Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf07.hostedemail.com (Postfix) with ESMTP id B537540003 for ; Mon, 27 Feb 2023 22:31:49 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=TGrLU8H8; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf07.hostedemail.com: domain of rick.p.edgecombe@intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=rick.p.edgecombe@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677537110; 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=se2s0CGLP/xSzdXeus2cLfjx/jzzmrnWH6Cj7Cnle5Y=; b=Ic65Fn28CvT4Sbdy+h6s3RGa/iAQxveelBb52WcKlmDwbDYjNML1IJonfM8fDH7hFfNPYK LHWK7WaETWobbnacuLv1CuJWNf/bjs+jZURPwyFbR6+dLBtLhncF5kssZG9FEHE1VSB8So VDuYf9PNBPPGREggN10p2eMHNfB/YL4= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=TGrLU8H8; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf07.hostedemail.com: domain of rick.p.edgecombe@intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=rick.p.edgecombe@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677537110; a=rsa-sha256; cv=none; b=G5gGzul5iHosOQ59+GFyh9GMD7kj6p60MOsVhfuijU2BAAUT8rdtGkIte3+w9L2jjIE3KM sB7efr4af1/W4PPsJWBeVVp1d8shdJgoQkbQVasBF2GMDVtqV2nu8Vy2GTQkFzh6At9Wll apKQiBWCzkOeuFoRfCV4qY4t1W6PFEU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1677537109; x=1709073109; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=g/mLbA9/W/OJJZ4lgb8cNHR8TFa9W9m/xYBMcnZGnDk=; b=TGrLU8H84lo76+Il3q/fc4WV+Tbxm5kfvpX7U+3nZ30qC7R8MCxXfy5M 5phzYuV5SYP51U8gll2iIjeoex0OotmucCnqy6vq5260p3zKutKUJjowc XsveOzGZXqfztocDDGytAT/nrTIHvmmt0faaVWNq7ZaPOFdNtFiLMzEaL fXGCvKe8YTaQfJmWAFPmiR+n6Nj5fMgdt8uOA/cbomguCnLppPRpbp1t+ 8lnQVL+BYEkBLE2igxWe0YUyapEIGvmQDE1UW963bvpfXBwo5ZjBVJ1p8 HybRnJhQIMKXmO1DABvRRsnZ8NsbgEQNQLaX6G8IkG3HJ/V+0HA9ldKOb g==; X-IronPort-AV: E=McAfee;i="6500,9779,10634"; a="313657566" X-IronPort-AV: E=Sophos;i="5.98,220,1673942400"; d="scan'208";a="313657566" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Feb 2023 14:31:25 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10634"; a="848024659" X-IronPort-AV: E=Sophos;i="5.98,220,1673942400"; d="scan'208";a="848024659" Received: from leonqu-mobl1.amr.corp.intel.com (HELO rpedgeco-desk.amr.corp.intel.com) ([10.209.72.19]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Feb 2023 14:31:25 -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 v7 24/41] mm: Don't allow write GUPs to shadow stack memory Date: Mon, 27 Feb 2023 14:29:40 -0800 Message-Id: <20230227222957.24501-25-rick.p.edgecombe@intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20230227222957.24501-1-rick.p.edgecombe@intel.com> References: <20230227222957.24501-1-rick.p.edgecombe@intel.com> X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: B537540003 X-Stat-Signature: t4snqdmaxeddo6mc9rn8r6amewhoq95n X-HE-Tag: 1677537109-171814 X-HE-Meta: U2FsdGVkX18mzwbKch672E2Bd0pNznZiCIAYCtT4jTukBax91OPYwthL8PMVabPijBYqouxJBudqcwMrhXedV1kAkxJRZJK+72tNTvJjtNONXTDLMjumpck3Rt+jrecUEejJ+pF5vvoWQUjWAknWCF+jNEvyR9TF2G9ukbBB/wgnTEPlHahkGkq851u7LW2RvYh7ZynBXiqzu6gzsEcFnA5jmqt1qqRWZXiIVNQBBOTrwa9dbWr53prgKTM8yGBPmJ9GW4GhlMvjrSezM2Qjq+DhwDC7AwIxdyi1jS0Q/Xt9yb43VrY4hpmo3Z1ZksfCG/zqjD2b/fdUYtt2ID7AiFgxgc9s1vjyeTYg/9MkcR+/s5WRQYlQucZtktkGw02WX17tLfH3krY7XuXdsDCdg5epAh0B0d4nk/87wez6z91nOO3Dd0dZHo2vIFhzSthKbSYDn5lYe1R+wdKESoYydYxPbVx9GuhHaWl5hgizWAGwToMfQ0iY4A2XtX8UudCswRb0GvczlfCMxRRzBH7zwkVcI1KL48DaSE6vYyWlRieZzERIjyAcaeQcklp89w5yZfVU75zbfPV8JeUDbxoL+JrabAAvnXn2gnja//5iaViHBGWEpIUU/OLjxi9IFFsU7A0BTmFAof7/9BlyttDHv9PuBXL9bNAtd5GNiyt9OiK6p2RaQUb3Gjd1PLT92zzpHhXJcxhsmy1gIZqk6Y0u+cBGkicSx5eJFs+d0ZW/3PWyxRndVydjaEl8R+Etsg0d6JGCYzypClRXymmpN52F6ZwyTKyCREJ6CrwCpQOC02M2aHTFeh7ZMVAGFCOd6wxN+0906DroP8PWDN09xhnlGkjEPE/8uBHZSNOpe/GPZT+xBY5EkIwvS5YwwNFXhs69sLS7E4LOmyYYxoNtqt/C7kDSSj7JAE2wai00MzKTazSkjXGcKioc4AdZ6jduE3XTOYnWL+nDmqRT3Exfjci Ln2HCgKV fiLui3CM8zGqppf7lTHYB0WifoHxk2Sm+d+6hP8N7NbnPljlGJDa2pYy0fl3g6ShYx0nTrForoB4X0blfudGfYQUkUujoouHLfQhGptWQteMZ+05PcsU7OI8lpIBLjB/kC6AwqjN3w2rsyUPue/D0cmQtjEuHRwhbtiBYbW+cvTti3fqI27pinfHCwWGTK0Kf/bcd1K1IcSiUBFIwmKiOMXNRjo4irw9UJ/RVxv6F4qd1NtgCXIyAG1pAEzhccrTy7tNueNiN/8L9Wg6aoHPXU/yqpFBW6GkTBZLMI75/WWHfJRU0gqYyr6Yr5gGl8g7QxHAUFu7SZg1Oglj62ByG7u8j0wiIa2y3DaQKXxugShZjTJyehoQLh+fRUg== 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. Tested-by: Pengfei Xu Tested-by: John Allen Tested-by: Kees Cook Acked-by: Mike Rapoport (IBM) Acked-by: David Hildenbrand Reviewed-by: Kees Cook Signed-off-by: Rick Edgecombe --- 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 d81e7ec27507..2e3d8cca1195 100644 --- a/arch/x86/include/asm/pgtable.h +++ b/arch/x86/include/asm/pgtable.h @@ -1638,6 +1638,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 eab18ba045db..e7c7bcc0e268 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -978,7 +978,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. */ -- 2.17.1