From patchwork Thu Jan 19 21:23:07 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rick Edgecombe X-Patchwork-Id: 13108807 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 36D67C004D4 for ; Thu, 19 Jan 2023 21:24:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 63C5D280006; Thu, 19 Jan 2023 16:24:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C3C4280001; Thu, 19 Jan 2023 16:24:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C84B280006; Thu, 19 Jan 2023 16:24:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 20855280001 for ; Thu, 19 Jan 2023 16:24:14 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E3EC980A3E for ; Thu, 19 Jan 2023 21:24:13 +0000 (UTC) X-FDA: 80372826786.28.5125EA4 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf27.hostedemail.com (Postfix) with ESMTP id DC4D34001A for ; Thu, 19 Jan 2023 21:24:11 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="gr8gr1/0"; spf=pass (imf27.hostedemail.com: domain of rick.p.edgecombe@intel.com designates 192.55.52.93 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=1674163452; 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=5Fw8vcaOAUH/Ghj13uHxxsRffcwnoPq1Ec7oLYAhwu4=; b=qTKVZyu5YXkjgNg2TOf9IV+nAtp33xNvtJs2/vZbwgLVYOhS/sY10DiX62pRFUcb3cG00I A3GFLN7DPAMSwAf6auWSQgDgQq/3oGvU0zVtpltmuS75gHv4zztrvN0u0nmFNrjiHfeino cTpDaXISQDR2Bc1tsYqKeEc/Umyjq4g= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="gr8gr1/0"; spf=pass (imf27.hostedemail.com: domain of rick.p.edgecombe@intel.com designates 192.55.52.93 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=1674163452; a=rsa-sha256; cv=none; b=To+IEarsMjFPgzXpiw+6O+Jo6EwkklLYbN+JrExcDwk3s2/zMelO3C9YtLF5IMqM7BAXYl JrWnGqff9iqD1ZNWzrURMfmWtwNkgEynPnOABdShBBF1TlUAG8Z3VWpzmg8kyPUUVTdKnC 2XjiGwFYBMqSnHM1Uj72PMzjTVUxz2s= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1674163451; x=1705699451; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=JqwiNktiNn9E4briGN+4X4+lTVwiARdl/uQ7DJ6w35c=; b=gr8gr1/0n+LsW//7KHpFG/gsbACNkRcISJKqDj4e2OxqoareP+8sm6p1 gZs9LprNKU+u9i2ftHvetuNWkDs9YXlZKJuLKl4jfyH82kb9eSEywH/7Q q0Kl2XQir5azrY+b2/o+Mk3XWZJ3u5fSnLy6HXbY8TyUBNk+vgOFpkGwD 1kc0ezF8vzFOaUstdKthr1gL81s4Y5A5kSgIyrDH3ZYbFwj/9s+gin4+Q f+kxkSVSPMI9CygP91bnlFErf5axAp6WrKdQykrQ3px4q1AVPKDyvqZV+ 3zkMXJFT/27fYvmHAfTaqoJBLcD9ej8PEfRtrkI5lOFdxRAtU2wJw4tDz Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10595"; a="323119888" X-IronPort-AV: E=Sophos;i="5.97,230,1669104000"; d="scan'208";a="323119888" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jan 2023 13:24:11 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10595"; a="989139145" X-IronPort-AV: E=Sophos;i="5.97,230,1669104000"; d="scan'208";a="989139145" Received: from hossain3-mobl.amr.corp.intel.com (HELO rpedgeco-desk.amr.corp.intel.com) ([10.252.128.187]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jan 2023 13:24:09 -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 Cc: rick.p.edgecombe@intel.com, Yu-cheng Yu Subject: [PATCH v5 29/39] x86/shstk: Introduce routines modifying shstk Date: Thu, 19 Jan 2023 13:23:07 -0800 Message-Id: <20230119212317.8324-30-rick.p.edgecombe@intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20230119212317.8324-1-rick.p.edgecombe@intel.com> References: <20230119212317.8324-1-rick.p.edgecombe@intel.com> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: DC4D34001A X-Stat-Signature: imy11835kr5omt5nc8q81p3e1aofyc7a X-Rspam-User: X-HE-Tag: 1674163451-96865 X-HE-Meta: U2FsdGVkX1/hc6ElvC6Jh2P+Xfxusr0exdhNzlwtyjquCHxHlJHi+DtdVylZXP7SuI02DJzQe9O1bloCmwD2FaliZ8JFuhAI8TOjmfcx6zluU6Pe48kL5U9lKJ9MUd228jsgKTOOZn0n10L4dNxm8TWqZv+HPP3gBU9ifb3OJjg2FWTQkz4m4CzZy1/C4FQDYQXVYxcQpsUSNCvV9wfX7J2J8l8hRFKL+yr60KCmco+7MSHKmYVO/sVA9q1EmpCKnQb4qEYhPvA9iu1FJQlfehkTZ6EGIRie8ZJp7mgehx0WVYgQ6ExwVjDttteUYm09kHRFf0RnccepLCQTsRuYM0HRxfnkIz6BZr1xbbKn/4qxhTSvZCliWoE5CLFt6ZlRjlNGjrbVhYpEX83gnF3LXzguBAg1ET5VMCTyMqbjf/yiQHse9bAZsMDDDpnoltffmhzT5vW55HO893Cka4xalwiAqVLpduyM8jpusEaqiIqP2r9eR8V68lqbFVuN8Kb7hrdoj9+4gwW5FGCxTkflNK73LURkTiZskYps1sCSh83QDjtp3wD3llCCjL5cIvJJ3UdWL2Bbf9imi4qJNQ+nuDoJYcyvAcYYynMOLjHoFjYskSALt84Hgt0m3sBPhPx4OkUwxjrxav0I3tco+HU4Bs60ZfCMytHFBhcEvO4tILdja8fFCuE8XleTewyOr2oQpR6Do5Is1JqNju7IU9/Pzd17GFY6/zW+i0+52heiUMmTvVFgFFjyt2JNJpNd1z2QYsayN1PO3X5QpH8slQdH59uyVPrKPriqk3FsVZJ3AR1L7VxCs7F3tr0hDvl3knrcYoGGxU9Wd4SKklfrT0Q5YwnpvHc/MQbM4r+8Bn6jggU7V331d7iUg7foKMDizOQNLkge+Yz5bFCl2gOtTGPWtocSnvs/TA0/oi+R1DvBXEhFBNhTKzsdireQXG9Lo4EdU9J5c2iK64c7UIx+TkX e19ppzJu 1OLb7IOS0DcL5RQIbif4U3sa8tkluxzwh+7Bp7Ya7Gf3RKXZuHoLDDEoranZjcXBq2BzPjZ/aIWcSUQZXXK/RS5P+wiAvFGHeULbJ5n/30GDdNeebYTnZTjombW5iTOnGGgQqT4vdYsScpPECbJeQJck5uE6U5C8LHwg0omseZpbpXQftnyX8fIdUddSOjcJxGGDobbFt+fFX1hHkdumWKs53xzAcO3NIN6ERPXKmBFVQln0D33VtDvyr7KpDeXgcyouuoy4Phfpu/wdXPjhpB0LreHZ2JydPV80r 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: From: Yu-cheng Yu Shadow stacks are normally written to via CALL/RET or specific CET instructions like RSTORSSP/SAVEPREVSSP. However during some Linux operations the kernel will need to write to directly using the ring-0 only WRUSS instruction. A shadow stack restore token marks a restore point of the shadow stack, and the address in a token must point directly above the token, which is within the same shadow stack. This is distinctively different from other pointers on the shadow stack, since those pointers point to executable code area. Introduce token setup and verify routines. Also introduce WRUSS, which is a kernel-mode instruction but writes directly to user shadow stack. In future patches that enable shadow stack to work with signals, the kernel will need something to denote the point in the stack where sigreturn may be called. This will prevent attackers calling sigreturn at arbitrary places in the stack, in order to help prevent SROP attacks. To do this, something that can only be written by the kernel needs to be placed on the shadow stack. This can be accomplished by setting bit 63 in the frame written to the shadow stack. Userspace return addresses can't have this bit set as it is in the kernel range. It is also can't be a valid restore token. Tested-by: Pengfei Xu Tested-by: John Allen Signed-off-by: Yu-cheng Yu Co-developed-by: Rick Edgecombe Signed-off-by: Rick Edgecombe Cc: Kees Cook Reviewed-by: Kees Cook --- v5: - Fix typo in commit log v3: - Drop shstk_check_rstor_token() - Fail put_shstk_data() if bit 63 is set in the data (Kees) - Add comment in create_rstor_token() (Kees) - Pull in create_rstor_token() changes from future patch (Kees) v2: - Add data helpers for writing to shadow stack. v1: - Use xsave helpers. arch/x86/include/asm/special_insns.h | 13 +++++ arch/x86/kernel/shstk.c | 73 ++++++++++++++++++++++++++++ 2 files changed, 86 insertions(+) diff --git a/arch/x86/include/asm/special_insns.h b/arch/x86/include/asm/special_insns.h index de48d1389936..d6cd9344f6c7 100644 --- a/arch/x86/include/asm/special_insns.h +++ b/arch/x86/include/asm/special_insns.h @@ -202,6 +202,19 @@ static inline void clwb(volatile void *__p) : [pax] "a" (p)); } +#ifdef CONFIG_X86_USER_SHADOW_STACK +static inline int write_user_shstk_64(u64 __user *addr, u64 val) +{ + asm_volatile_goto("1: wrussq %[val], (%[addr])\n" + _ASM_EXTABLE(1b, %l[fail]) + :: [addr] "r" (addr), [val] "r" (val) + :: fail); + return 0; +fail: + return -EFAULT; +} +#endif /* CONFIG_X86_USER_SHADOW_STACK */ + #define nop() asm volatile ("nop") static inline void serialize(void) diff --git a/arch/x86/kernel/shstk.c b/arch/x86/kernel/shstk.c index 111ea56115d2..3e470917eb0b 100644 --- a/arch/x86/kernel/shstk.c +++ b/arch/x86/kernel/shstk.c @@ -25,6 +25,8 @@ #include #include +#define SS_FRAME_SIZE 8 + static bool features_enabled(unsigned long features) { return current->thread.features & features; @@ -40,6 +42,35 @@ static void features_clr(unsigned long features) current->thread.features &= ~features; } +/* + * Create a restore token on the shadow stack. A token is always 8-byte + * and aligned to 8. + */ +static int create_rstor_token(unsigned long ssp, unsigned long *token_addr) +{ + unsigned long addr; + + /* Token must be aligned */ + if (!IS_ALIGNED(ssp, 8)) + return -EINVAL; + + addr = ssp - SS_FRAME_SIZE; + + /* + * SSP is aligned, so reserved bits and mode bit are a zero, just mark + * the token 64-bit. + */ + ssp |= BIT(0); + + if (write_user_shstk_64((u64 __user *)addr, (u64)ssp)) + return -EFAULT; + + if (token_addr) + *token_addr = addr; + + return 0; +} + static unsigned long alloc_shstk(unsigned long size) { int flags = MAP_ANONYMOUS | MAP_PRIVATE | MAP_ABOVE4G; @@ -160,6 +191,48 @@ int shstk_alloc_thread_stack(struct task_struct *tsk, unsigned long clone_flags, return 0; } +static unsigned long get_user_shstk_addr(void) +{ + unsigned long long ssp; + + fpregs_lock_and_load(); + + rdmsrl(MSR_IA32_PL3_SSP, ssp); + + fpregs_unlock(); + + return ssp; +} + +static int put_shstk_data(u64 __user *addr, u64 data) +{ + if (WARN_ON_ONCE(data & BIT(63))) + return -EINVAL; + + /* + * Mark the high bit so that the sigframe can't be processed as a + * return address. + */ + if (write_user_shstk_64(addr, data | BIT(63))) + return -EFAULT; + return 0; +} + +static int get_shstk_data(unsigned long *data, unsigned long __user *addr) +{ + unsigned long ldata; + + if (unlikely(get_user(ldata, addr))) + return -EFAULT; + + if (!(ldata & BIT(63))) + return -EINVAL; + + *data = ldata & ~BIT(63); + + return 0; +} + void shstk_free(struct task_struct *tsk) { struct thread_shstk *shstk = &tsk->thread.shstk;