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 E551CC64EC4 for ; Thu, 9 Mar 2023 16:48:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F29BB280001; Thu, 9 Mar 2023 11:48:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EDA346B0072; Thu, 9 Mar 2023 11:48:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA1C8280001; Thu, 9 Mar 2023 11:48:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C9E7F6B0071 for ; Thu, 9 Mar 2023 11:48:55 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8E0EC120978 for ; Thu, 9 Mar 2023 16:48:55 +0000 (UTC) X-FDA: 80549944230.29.727A03B Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf12.hostedemail.com (Postfix) with ESMTP id BF9B74001B for ; Thu, 9 Mar 2023 16:48:47 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=temperror ("DNS error when getting key") header.d=alien8.de header.s=dkim header.b=oLq0+xRx; spf=temperror (imf12.hostedemail.com: error in processing during lookup of bp@alien8.de: DNS error) smtp.mailfrom=bp@alien8.de; dmarc=temperror reason="SPF/DKIM temp error" header.from=alien8.de (policy=temperror) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678380531; a=rsa-sha256; cv=none; b=FzIl+rJUbRcrZr2LSBlyH7dOY/Ya0+loWdMa15e+S406bP5CuyQeftW3Lc17h2C+Jsccm+ wYa9XYfzC0HRq/+zb7vTrwJIaZgbk8hgN8v3z5oHQXkrypWoWiJYPZvttKEb2UQNYl4rKp lO0rTHeGiF6wJJpYEO1xn8A1mbzcCZM= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=temperror ("DNS error when getting key") header.d=alien8.de header.s=dkim header.b=oLq0+xRx; spf=temperror (imf12.hostedemail.com: error in processing during lookup of bp@alien8.de: DNS error) smtp.mailfrom=bp@alien8.de; dmarc=temperror reason="SPF/DKIM temp error" header.from=alien8.de (policy=temperror) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678380531; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=y9fgVkJaonsv4Fq61FCxxoW1/dZqwLtrdhcT+JC/0gI=; b=1urWIV6KF6hMTnW21Ye50XXZex3HPi8j+d7oY1MkcfbhfiB4+iLQoVkH+rmC+1R/nE8ZzK 2bJ/6zLh5KCtnVMCi2iSvRhV+31S+urcd/mwyC4zehfwvuwjeD9tsNIkH5pxY+DEFAgU2S nYKEfkz9LZlwHgFEs1JCv4ixKSo3pFY= Received: from zn.tnic (p5de8e9fe.dip0.t-ipconnect.de [93.232.233.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id B22151EC0464; Thu, 9 Mar 2023 17:48:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1678380525; 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:in-reply-to:in-reply-to: references:references; bh=y9fgVkJaonsv4Fq61FCxxoW1/dZqwLtrdhcT+JC/0gI=; b=oLq0+xRxpNxRF+7gFw40PrZBhMfN77YRoJympjw43zS4MFdGKCzTRi2By/ji9HJjNc7h7U O4mLJEfDttVF77nmvJWKyLxI3QXpfxZpZ0BF59AdTDPitGajtBIoCGPq1vS/PbRvDVzRYR muTbKHWIQuzKGhFAr+6/DSiudLrczeE= Date: Thu, 9 Mar 2023 17:48:42 +0100 From: Borislav Petkov To: Rick Edgecombe Cc: 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 , 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, Yu-cheng Yu Subject: Re: [PATCH v7 31/41] x86/shstk: Introduce routines modifying shstk Message-ID: References: <20230227222957.24501-1-rick.p.edgecombe@intel.com> <20230227222957.24501-32-rick.p.edgecombe@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20230227222957.24501-32-rick.p.edgecombe@intel.com> X-Rspam-User: X-Rspamd-Queue-Id: BF9B74001B X-Rspamd-Server: rspam01 X-Stat-Signature: 651my7zpotxy1xhfhntjeqbjg144twuu X-HE-Tag: 1678380527-101225 X-HE-Meta: U2FsdGVkX18YzkZNo/Di9L1q3Pk1Me3vJkWMQBy4ls9AlXPzuLjII7+3XC9bBveW6glHzwK4ekfMULj0D49r2swBmyO5Spgbq8BeZbZzQRqnvT/gSmELU8/LJn38PmtWrRQgbI9yLPtN8x14g2geynw5uzwdXWsVyPPDYgZx3tSiAc3WevWC6XvSA884x8agdSqKb9cQTLkyURGRZwGbJ1+bZi6BuvM/GfAnBVhZEp1QBDb3fi1SnQXoKwnIfUb179XPtCO7KHPnzH7AIXnG4jjLZ0aEFnUiUIDLEIko7pPuSni0HivrD5dfCLE23d4W1pH54AIhI4onPPkuyAymY43L6rTKY4sB9mh0lbZY7BY3LK6j0TINdhbs0lqVv17nyIbMARmH7SlvLOmkeKz4nAmZqOC8eajTnwvsEeVQ3H3z4O5nrijUzSCjdZjMMqW5CQKefG/3VABuMH9VG0DIucbkd7KeWutwgvD/ZIRf1pf/ctHtrASGNx5p8jqfmoOXlArYVbk8H11s5Jp85PCyBa0f53dgCw8idJtdFsQ9MoYXFyoSXHbA+Yxi6UA5lbfPEWyfpw/RlMCUBrjoQTM3jMx9UKgBkz6fAvf2swk2NcYtT7Rqdp/EuXo0NFLkn2mvwIV1kZeVYzI80T3hDUDXGOaIFoh8UOF5znMY9pGTIxIeX90sMVYXJHgTS4MA48sR9Lk8toGVxWyELAy4MMxzYCnmPt1lFwdLm2d2NnX8IzGN0CxuHeoUPDCIbpaY81M07W7YZqK0k1BbeuTmRIVy1AWfd2Zr5aCP3a9eXYlkNb3cLDVj7m7ffRK4C1RRUae9kFFKZl6QWiuxCQ8Mo5YwoKuqqkPB0rvRKLZRdAgpU1crmqptuX7wB9xr3ld5Ip2Yio9Yf1jcnCBeGmtdgvJN8+poWdr9bExe9QNWApb9H1c+nZe3+JEYca+BWb2hiKcrB0jInnjwzlGkjRnchrD wtX5yjK8 RUY5Ec4CsgrjGovUoK0WtK1G/wGDJM2ptypg9f16zzSB4jGDj2W+2r/bwjfqPAXjQokU9avgVVUn3+KbkK+BW5NRpxuM7ahgvUSnF77Z6R1DOESi0heO9iHxxtlz/5pwHXtl4v2YaQAMvMIdHCPZIaLuCHmUK5B/4skEDPEx8whNWsbgQwCmjgUcNpyidI9gNWBqbtnFTqdT6icNk8xim1jOVi5VruzQxaPS7Q0v1xRf5NNWs76Twmk5veAWCiz/sCf9cC3MHN6Si/GLseRCjiW0HsBVJDA5q9u3WXQ/VKlalA39Mp+PMao0J0rUQkSAqDLVZvXSjJZ7V/3End6LX3+LK1PEZcoHFBo/WPSZBYd8VhylxoO35+d2faJ7dB1NFpIedKdh2WeMi4bHv6BxP0vEfIS6AAAOomizRWhmFJq6zXpo8BaUz1EeD2Kk4fIRjCz1M 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 Mon, Feb 27, 2023 at 02:29:47PM -0800, Rick Edgecombe wrote: > From: Yu-cheng Yu > > Shadow stacks are normally written to via CALL/RET or specific CET ^ indirectly. > instructions like RSTORSSP/SAVEPREVSSP. However during some Linux > operations the kernel will need to write to directly using the ring-0 only "However, sometimes the kernel will need to..." > 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 s/is // > valid restore token. ... > 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; Nice! > +} > +#endif /* CONFIG_X86_USER_SHADOW_STACK */ > + > #define nop() asm volatile ("nop") > > static inline void serialize(void) ... > +static int put_shstk_data(u64 __user *addr, u64 data) > +{ > + if (WARN_ON_ONCE(data & BIT(63))) Dunno, maybe something like: /* * A comment explaining what that is... */ #define SHSTK_SIGRETURN_TOKEN BIT_ULL(63) or so? And use that instead of that magical bit 63. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette