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 0CFB9C64EC4 for ; Thu, 9 Mar 2023 17:02:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 70877280002; Thu, 9 Mar 2023 12:02:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 69270280001; Thu, 9 Mar 2023 12:02:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5336F280002; Thu, 9 Mar 2023 12:02:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3E717280001 for ; Thu, 9 Mar 2023 12:02:38 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 073AA81003 for ; Thu, 9 Mar 2023 17:02:38 +0000 (UTC) X-FDA: 80549978796.14.4EB6620 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf01.hostedemail.com (Postfix) with ESMTP id 431F040023 for ; Thu, 9 Mar 2023 17:02:33 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=alien8.de header.s=dkim header.b=UTIj0bjN; spf=pass (imf01.hostedemail.com: domain of bp@alien8.de designates 5.9.137.197 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678381355; 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=2EzHzmcCNV+hERnYGLmd7J3Hxny9vW/fCLbxwPiF+nY=; b=szggUbItEXJKn8uq+zeBw4Z02vv8MQQGJK42tBucpYv/V0m6KTIfm2X6WugaLenSerKjJU 9GZZWkBxHouRw7XYDKe0u4g8wUG0uCFv4Aluf8GQPhQBKXEGrc5dKmwOvn0kr1ou0iBi42 tByrtc5vV2SXX6+v8CuOFUrJsUvoGxQ= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=alien8.de header.s=dkim header.b=UTIj0bjN; spf=pass (imf01.hostedemail.com: domain of bp@alien8.de designates 5.9.137.197 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678381355; a=rsa-sha256; cv=none; b=vjPrIVEDEuG02FrOM7Atd0FIxy2NiYSC1reqZg9q7n79xRc+X3TRZm/1EwOGhJn6s96sRz eYgTQDZtE/waK4VeRoXKNY6sKUlb12TEpnV3UiOdtq/YUlf1JJ6xN/QaQu/Td0tEe/hZ3e e0P5OKnNplyH4qTtqyL4VGvsjtYSMjY= 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 206C81EC0464; Thu, 9 Mar 2023 18:02:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1678381352; 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=2EzHzmcCNV+hERnYGLmd7J3Hxny9vW/fCLbxwPiF+nY=; b=UTIj0bjNQ8tGPkfWd7G2gwZV3Qvhn3M5rZhVEwIFvbwSC1ecnxrHBw99KYD7QFpw2tp7lp LW+Cp843oRJRVtsLOq8At1/Ut0Pr+dpLc+U8aHStU+1wD8bWxDsjPoyJ5WsOmAcB4VvhDJ qW9JffSymArXGmcDl7niUASKvz7y7wA= Date: Thu, 9 Mar 2023 18:02:27 +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 32/41] x86/shstk: Handle signals for shadow stack Message-ID: References: <20230227222957.24501-1-rick.p.edgecombe@intel.com> <20230227222957.24501-33-rick.p.edgecombe@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20230227222957.24501-33-rick.p.edgecombe@intel.com> X-Rspamd-Queue-Id: 431F040023 X-Stat-Signature: gnu6sqom3idspg1cadrbudzkkcx96yae X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1678381353-584740 X-HE-Meta: U2FsdGVkX1+hxCDNl51+Gey613lVtdoXD9F/R8eiPJzojvb/sonCwiSTPPxDXZr+pg2vCJoyWoKDlJvIbXigh8Fp0BL6kXsO1lyZWDFdDfwEF4x1eWD2EbILKE+GFvgJmJzdMF9qaxcMlGAuKgDl6O9pfSbN66MzN10/L6i5/+yLI1lH1wIryV4gKk5XNJcAqNGxK+DkiAXlQRvIKvH8LSSetkswzv97IpUFNcCB8jgNniZJcOCLH4HleZ0Nqkar2ZYs2Ws8Q8YLqrwpCRDm0kxFGVAcZETsfUkldLcUG/ZhfElHNNlbBtv9yKFkE1ur09ROX/AMSjNO4rSRRoKTMT6PrkX1xlSIoBZ1I6HH5Z9gmVWZK/YJ97EXnhFxnT83Vc0/CBgUlLEg2N0vEfwrP9jOkskkcrSx5ycIaXm2wLasRGWxSNbQaVoUvqMjATgB6++yzQBWM4B7GJoxn72JNaEgzWc24pKNw9E8iiwPAGDyQCrg0tyE4G+aE734IZJb6m9GMrZJ6QuS1L3J++6kH85AhCkY4vAXRQNCHDWrwX2t747a4MmRkVbBn4gcMojcaqhzaIM2ydrWpmeB8fyrYIR1LxjwH/6wdy/JlkVxTuLH3u4cEEULWrwtRTSozTtNvqRG31WhJ3TbWtIYtt/0FzWj6OFvDqewE0i0txUp2dXRFe9IzZM8OhVmcIent+mTxZ0TzLWzFzZFCEQaxdx3pwcD/FNwbs2zxri2jCOgF6OM5Nc6u0J166zgcHQccl9tVSKYt5uaVgdW5uW6E62cmzUJIZyoC7v6+sYXH1ys613WIIpymehSSY/ceKwhCx8W71rIK9Nhp/xHnymVL6ZaywUnqi+yTMaZeh5zHSHzUOqPWePhbTWTM6geWRHOmSUgMq4bnfiZNKwXexyNVlfkU4jRQkvrRas6OqZDrydhxh6OeAy29FXwK5/ZfOp9xEZczP/CmR6JKz8bum0cYvT 27OevEAC 5twLuDdnC7oPxqnPHl1auFYrX53pujVXalgXdD0liPe+j8ZvSTlILTJAdgWvWjS1qj8SiTmbUoK5GCy24Hta+qapsOf7/lVHmu+RZNsuKTkBECw3ASIgsCz06OmMc/kDkjNaufu3DQyCU2lMKyWnxz3EvhOAGEmeytUh6uGNpwlCeXygpf0JV9aK0oGZX97yp/ynUtMp41dVqwsWUh5YFnlo/7CJyeMfIjkCa8biZZIkgcYjIxpVsQgp5ozcGy7UHpGsfSWxFUDXmds/KAfJPxgnlXoGOfECga15NpY1J2qtuGmrVYHTgKbzxgw== 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:48PM -0800, Rick Edgecombe wrote: > From: Yu-cheng Yu > > When a signal is handled normally the context is pushed to the stack s/normally // > before handling it. For shadow stacks, since the shadow stack only track's "tracks" > return addresses, there isn't any state that needs to be pushed. However, > there are still a few things that need to be done. These things are > userspace visible and which will be kernel ABI for shadow stacks. "visible to userspace" s/which // > One is to make sure the restorer address is written to shadow stack, since > the signal handler (if not changing ucontext) returns to the restorer, and > the restorer calls sigreturn. So add the restorer on the shadow stack > before handling the signal, so there is not a conflict when the signal > handler returns to the restorer. > > The other thing to do is to place some type of checkable token on the > thread's shadow stack before handling the signal and check it during > sigreturn. This is an extra layer of protection to hamper attackers > calling sigreturn manually as in SROP-like attacks. > > For this token we can use the shadow stack data format defined earlier. ^^^ Please use passive voice in your commit message: no "we" or "I", etc. > Have the data pushed be the previous SSP. In the future the sigreturn > might want to return back to a different stack. Storing the SSP (instead > of a restore offset or something) allows for future functionality that > may want to restore to a different stack. > > So, when handling a signal push > - the SSP pointing in the shadow stack data format > - the restorer address below the restore token. > > In sigreturn, verify SSP is stored in the data format and pop the shadow > stack. ... > diff --git a/arch/x86/kernel/shstk.c b/arch/x86/kernel/shstk.c > index 13c02747386f..40f0a55762a9 100644 > --- a/arch/x86/kernel/shstk.c > +++ b/arch/x86/kernel/shstk.c > @@ -232,6 +232,104 @@ static int get_shstk_data(unsigned long *data, unsigned long __user *addr) > return 0; > } > > +static int shstk_push_sigframe(unsigned long *ssp) > +{ > + unsigned long target_ssp = *ssp; > + > + /* Token must be aligned */ > + if (!IS_ALIGNED(*ssp, 8)) > + return -EINVAL; > + > + if (!IS_ALIGNED(target_ssp, 8)) > + return -EINVAL; Those two statements are identical AFAICT. > + *ssp -= SS_FRAME_SIZE; > + if (put_shstk_data((void *__user)*ssp, target_ssp)) > + return -EFAULT; > + > + return 0; > +} -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette