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 C9340C88CBA for ; Tue, 13 Jun 2023 00:12:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 02D0C8E0010; Mon, 12 Jun 2023 20:12:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 003E98E000B; Mon, 12 Jun 2023 20:12:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DE55F8E0010; Mon, 12 Jun 2023 20:12:24 -0400 (EDT) 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 C7ADB8E000B for ; Mon, 12 Jun 2023 20:12:24 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 95400AF12A for ; Tue, 13 Jun 2023 00:12:24 +0000 (UTC) X-FDA: 80895797808.01.877C9DD Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf19.hostedemail.com (Postfix) with ESMTP id 8D85F1A0002 for ; Tue, 13 Jun 2023 00:12:22 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Y9pbHl6R; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf19.hostedemail.com: domain of rick.p.edgecombe@intel.com designates 134.134.136.65 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=1686615142; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5fI2fz3C60mSydVE+2mwy8UwGqfU5Pn7fjr7hidomLc=; b=KdsgbmYp3w58p9RvLeJgRyklRTNj3rcd4IyAWGGWtVGgPSgm2ZiBf1ynKcz9+RIgN7xwGK 3pmjyTsB2l6YobFZNwKIPDTWxc1JdIFe3jsRUbACH+4I3pHMAD0w5zvQM2NSivWCzi4NWg 0G6JwqSMeZjVf6EXgkdKHSo/LKM3YWQ= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Y9pbHl6R; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf19.hostedemail.com: domain of rick.p.edgecombe@intel.com designates 134.134.136.65 as permitted sender) smtp.mailfrom=rick.p.edgecombe@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686615142; a=rsa-sha256; cv=none; b=0uXiu6aeaMiZALdzG3/E3OWglV5C4738aAd2+i3dwL3fjIKaTxdbDmw7/dzfa+7DyD8JyF DX2K8I7rLyni9VVq7mqa1LpKekUZH/UT6CPKoQn/dkS6NUGJMxGqCV0F+EMv6S/xDcxPK7 +ihB+1wpKOBbcnuMxV4PPA7NY4XtRvk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1686615142; x=1718151142; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=VxsR8A3vgFZdU2Uya7vVGhJBClJyO0tAkA+BqmUO8Zs=; b=Y9pbHl6Rgr0QGmaQrexViFiapsK9KJ751LLn8cHKI6FH3jr9RukwNCkf 2mFQoeoa812EkOaG/c/kWlmvGGczOYjZhR13e4ICDyPmkQpWjSC1MNd+c UkK1YRfi85GCLXzAAp8YWOuaCqxq83YEC6yzFmYS5g+HhiLGr2ifZ2k53 iu2ozY0p+QCq0nKWmO28KfLHkfC17FgV3bVwDcCcQuoakkAgp0fpJECoU ikhiz2yfpBLx6cWrFe12gyJ+RMIrGsEqfTNc3TipONT1d+Xxz7JZYtgQB YAg735kcgj3Lvguii3UROk0WUBBqD5pDHWArW7Y7wdKnspPG+MqqjEe5Q A==; X-IronPort-AV: E=McAfee;i="6600,9927,10739"; a="361557009" X-IronPort-AV: E=Sophos;i="6.00,238,1681196400"; d="scan'208";a="361557009" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jun 2023 17:12:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10739"; a="835671026" X-IronPort-AV: E=Sophos;i="6.00,238,1681196400"; d="scan'208";a="835671026" Received: from almeisch-mobl1.amr.corp.intel.com (HELO rpedgeco-desk4.amr.corp.intel.com) ([10.209.42.242]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jun 2023 17:12:20 -0700 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, szabolcs.nagy@arm.com, torvalds@linux-foundation.org, broonie@kernel.org Cc: rick.p.edgecombe@intel.com, Yu-cheng Yu , Pengfei Xu Subject: [PATCH v9 15/42] x86/mm: Check shadow stack page fault errors Date: Mon, 12 Jun 2023 17:10:41 -0700 Message-Id: <20230613001108.3040476-16-rick.p.edgecombe@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230613001108.3040476-1-rick.p.edgecombe@intel.com> References: <20230613001108.3040476-1-rick.p.edgecombe@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 8D85F1A0002 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: t5hdtxbhgn1ycofuhfzdd6x8o4iw5fsj X-HE-Tag: 1686615142-283420 X-HE-Meta: U2FsdGVkX19OrtyeQGWFgxpkHWiEmvNdfI8txSrnLXaBJGfCY3aHeoygLdfXW3uF/8EgfTCefxQ3JiFaivnpS+MHzD9R+HVAKp2RuvJ8xEU7JVbBa0quxX3I6an38dp5/TINiI2N11V/w9FQb7HQES4Us7fzIafpsdYyaPXk907DezDd2KWvXF4qdFLjhdoiRRhMD555nmc/EoNIR7wO5m2ifiHcVwEaop/QndWC3xuR0cXkX2PBAK/5eRN0Nb28ymhW9CcWYg6L3TQtVaR9AqWaa5rQq0SknLLTwoY6ohiBl61VHZOlH+b3Bf3kO3+34g9yc6HJIeJIyALw0+0i2Q49FPBsow7hok1WQdclPchegVoXgBNsRi4Z9HXFnbEGHBgNEp0Y3yF+swOnqp6CMjYwxDJhoK2dB6/PHtxd7mMh+OkUtpagm0U58feLMis/GLlmeJbJfgQ/gZuEyvUgEfJv/IXTlLaXt6acZRPzPh5cOnEaMdk3YQJdzfuAiESlauh3SooFz23re+8IUNnKOBp0wQjpVPNPQIgTHRoyYx+oN7ZWSFMZUeM3aTZ+rg3ABcbvYHxN9MOLwbDvfORx8/RkMdq00fhg5gDCV/Ro3CERBmLhGB+tQTvKyKVNipnGVLM9KhoGxkRJHzUWXGIxMjMWTsW5tXTD7LlvaqStgw1E3Zg4gk3X7M0nopVqhsUN3IDOfWofrYxWVW9/MQ1OytnMNRakAGjbaf9kbNV8O7sGpQkbKADgMbtK+8/n2WMOB+9GQkRQoWCIHLP/FBhyqbUUGAWeHyYVusIKrv2efqztUAL+6ZnJFWlskt9451Z95BTzW7u+GrYQ3tgOG1fABit47tJGY+O0oUkBJ3PX4t8OFEu034UANgduZJXPOwUiW/lWw5VXyQxYV9MfNvmN37d09Tkvba77kiNuEhsw0viaUi0TUZYZsdpNn8Taoj6+7wWurxfQsA68ir/Y5vw TC8B/C+W UH/1VDchZZqH+Rgy1IQ3Gfr8X4q4PRL8s5OFYBMBtVA337exC3bupKUsSgt5KXLOUz7dCsMIjxRttLrl8Mjc7o4jMn1QJh8ZJBmQ9vWWicVuKej7uphWEUn3HRna0y3T5cRQf8pIY1NaaNLz+6VV28N7POiur9fyZ14uoo4v2LbGf9qZIh3wX0DWI1B6lVy/RzjbnysVhmvtkxCk9SuMRKwrHHJhK7jWl4gSzOz4ngjJvYh1suz8W2mKWQEE6JqO7nQCyyl5v1a4ogGu3EXk5jX3XfC4IbNDVx7rErEIhxd8jdfWGi+KAWiKG3T+oKs0NFVJ1p2Y78DRwldk3OUqFI9Fx0ciUies8CCETKJQ9ON7dHtSrohOukEuKTA== 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 CPU performs "shadow stack accesses" when it expects to encounter shadow stack mappings. These accesses can be implicit (via CALL/RET instructions) or explicit (instructions like WRSS). Shadow stack accesses to shadow-stack mappings can result in faults in normal, valid operation just like regular accesses to regular mappings. Shadow stacks need some of the same features like delayed allocation, swap and copy-on-write. The kernel needs to use faults to implement those features. The architecture has concepts of both shadow stack reads and shadow stack writes. Any shadow stack access to non-shadow stack memory will generate a fault with the shadow stack error code bit set. This means that, unlike normal write protection, the fault handler needs to create a type of memory that can be written to (with instructions that generate shadow stack writes), even to fulfill a read access. So in the case of COW memory, the COW needs to take place even with a shadow stack read. Otherwise the page will be left (shadow stack) writable in userspace. So to trigger the appropriate behavior, set FAULT_FLAG_WRITE for shadow stack accesses, even if the access was a shadow stack read. For the purpose of making this clearer, consider the following example. If a process has a shadow stack, and forks, the shadow stack PTEs will become read-only due to COW. If the CPU in one process performs a shadow stack read access to the shadow stack, for example executing a RET and causing the CPU to read the shadow stack copy of the return address, then in order for the fault to be resolved the PTE will need to be set with shadow stack permissions. But then the memory would be changeable from userspace (from CALL, RET, WRSS, etc). So this scenario needs to trigger COW, otherwise the shared page would be changeable from both processes. Shadow stack accesses can also result in errors, such as when a shadow stack overflows, or if a shadow stack access occurs to a non-shadow-stack mapping. Also, generate the errors for invalid shadow stack accesses. Co-developed-by: Yu-cheng Yu Signed-off-by: Yu-cheng Yu Signed-off-by: Rick Edgecombe Reviewed-by: Borislav Petkov (AMD) Reviewed-by: Kees Cook Acked-by: Mike Rapoport (IBM) Tested-by: Pengfei Xu Tested-by: John Allen Tested-by: Kees Cook --- arch/x86/include/asm/trap_pf.h | 2 ++ arch/x86/mm/fault.c | 22 ++++++++++++++++++++++ 2 files changed, 24 insertions(+) diff --git a/arch/x86/include/asm/trap_pf.h b/arch/x86/include/asm/trap_pf.h index 10b1de500ab1..afa524325e55 100644 --- a/arch/x86/include/asm/trap_pf.h +++ b/arch/x86/include/asm/trap_pf.h @@ -11,6 +11,7 @@ * bit 3 == 1: use of reserved bit detected * bit 4 == 1: fault was an instruction fetch * bit 5 == 1: protection keys block access + * bit 6 == 1: shadow stack access fault * bit 15 == 1: SGX MMU page-fault */ enum x86_pf_error_code { @@ -20,6 +21,7 @@ enum x86_pf_error_code { X86_PF_RSVD = 1 << 3, X86_PF_INSTR = 1 << 4, X86_PF_PK = 1 << 5, + X86_PF_SHSTK = 1 << 6, X86_PF_SGX = 1 << 15, }; diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index e4399983c50c..fe68119ce2cc 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -1118,8 +1118,22 @@ access_error(unsigned long error_code, struct vm_area_struct *vma) (error_code & X86_PF_INSTR), foreign)) return 1; + /* + * Shadow stack accesses (PF_SHSTK=1) are only permitted to + * shadow stack VMAs. All other accesses result in an error. + */ + if (error_code & X86_PF_SHSTK) { + if (unlikely(!(vma->vm_flags & VM_SHADOW_STACK))) + return 1; + if (unlikely(!(vma->vm_flags & VM_WRITE))) + return 1; + return 0; + } + if (error_code & X86_PF_WRITE) { /* write, present and write, not present: */ + if (unlikely(vma->vm_flags & VM_SHADOW_STACK)) + return 1; if (unlikely(!(vma->vm_flags & VM_WRITE))) return 1; return 0; @@ -1311,6 +1325,14 @@ void do_user_addr_fault(struct pt_regs *regs, perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address); + /* + * Read-only permissions can not be expressed in shadow stack PTEs. + * Treat all shadow stack accesses as WRITE faults. This ensures + * that the MM will prepare everything (e.g., break COW) such that + * maybe_mkwrite() can create a proper shadow stack PTE. + */ + if (error_code & X86_PF_SHSTK) + flags |= FAULT_FLAG_WRITE; if (error_code & X86_PF_WRITE) flags |= FAULT_FLAG_WRITE; if (error_code & X86_PF_INSTR) -- 2.34.1