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 EEB74C433F5 for ; Tue, 4 Oct 2022 17:46:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7ABAD6B0071; Tue, 4 Oct 2022 13:46:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 75AAD6B0073; Tue, 4 Oct 2022 13:46:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D3F26B0074; Tue, 4 Oct 2022 13:46:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 4B5506B0071 for ; Tue, 4 Oct 2022 13:46:43 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 08AEC120EB3 for ; Tue, 4 Oct 2022 17:46:43 +0000 (UTC) X-FDA: 79983997086.30.55D9C34 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf12.hostedemail.com (Postfix) with ESMTP id 5688240015 for ; Tue, 4 Oct 2022 17:46:42 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9E9C1614ED; Tue, 4 Oct 2022 17:46:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8BBC2C433D6; Tue, 4 Oct 2022 17:46:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1664905601; bh=4BSaUvrlCCPRQCV8MWBWOtBwSsI5CjjkAG/AXZX56MU=; h=In-Reply-To:References:Date:From:To:Subject:From; b=nGHzwTtzDeAUdK1Nz3MDl8munGmB9RGTvZ9Lh4V2lRA4KkSgzw91WY2jfgYMzAW3J QiZFo4t8IrZJmj5RabGjxlxGYdb1HaVYKHwjX0b9KMYVd9e8ngyPMItDRzYHWdLCt+ 0wPD+bfhofunIetIX/r0SlgisZJx5jp8T7ul+/loOh/Vv08EGyXdDAdBCkv9RP56Qh liS/n1Q9Odvq91rXOIw6lRS+KqvHcFLdGfti7tCLbceZyzrbiuGXclGErGozW4yjBZ f/mNTNp15tiEUqAoFDLrkNZGw/KrKwqLA2JJR7w3y1uMlgswgCtjHrlqP7ZpotMHgx AUpOHdCijBjbg== Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id 665E827C0054; Tue, 4 Oct 2022 13:46:38 -0400 (EDT) Received: from imap48 ([10.202.2.98]) by compute2.internal (MEProxy); Tue, 04 Oct 2022 13:46:38 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeeiuddguddujecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedftehn ugihucfnuhhtohhmihhrshhkihdfuceolhhuthhosehkvghrnhgvlhdrohhrgheqnecugg ftrfgrthhtvghrnheptdfhheettddvtedvtedugfeuuefhtddugedvleevleefvdetleff gfefvdekgeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homheprghnugihodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeiudek heeifedvqddvieefudeiiedtkedqlhhuthhopeepkhgvrhhnvghlrdhorhhgsehlihhnuh igrdhluhhtohdruhhs X-ME-Proxy: Feedback-ID: ieff94742:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id B662E31A0062; Tue, 4 Oct 2022 13:46:37 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1015-gaf7d526680-fm-20220929.001-gaf7d5266 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20220929222936.14584-1-rick.p.edgecombe@intel.com> <20220929222936.14584-40-rick.p.edgecombe@intel.com> Date: Tue, 04 Oct 2022 10:46:17 -0700 From: "Andy Lutomirski" To: "Rick P Edgecombe" , "Balbir Singh" , "H. Peter Anvin" , "Eugene Syromiatnikov" , "Peter Zijlstra (Intel)" , "Randy Dunlap" , "Kees Cook" , "Dave Hansen" , "Kirill A. Shutemov" , "Eranian, Stephane" , "linux-mm@kvack.org" , "Florian Weimer" , "Nadav Amit" , "Jann Horn" , "dethoma@microsoft.com" , "linux-arch@vger.kernel.org" , "kcc@google.com" , "Borislav Petkov" , "Oleg Nesterov" , "H.J. Lu" , "Weijiang Yang" , "Pavel Machek" , "Arnd Bergmann" , "Moreira, Joao" , "Thomas Gleixner" , "Mike Kravetz" , "the arch/x86 maintainers" , "linux-doc@vger.kernel.org" , "jamorris@linux.microsoft.com" , "john.allen@amd.com" , "Mike Rapoport" , "Ingo Molnar" , "Shankar, Ravi V" , "Jonathan Corbet" , "Linux Kernel Mailing List" , "Linux API" , "Cyrill Gorcunov" Subject: Re: [OPTIONAL/RFC v2 39/39] x86: Add alt shadow stack support Content-Type: text/plain ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664905602; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=CHgiTsPxDByi2IuviJGK1BnZNfruPQX+If05YZEVzVg=; b=g9kAV3qT4lXLcG0TCYhlS1jm+b7dcepeFFUP30rX7kHf4KnV65DPdiUg6QE+iqcylJ5z0T AuGYXrBoQ9X+VYoKSsRfGGoljFYoMOzZE1K1AAZJ62mJ8zDFKY4UdL9ILVuAI5y7bExEHp lOX/c6nW0DO/sZ+R7YkPwzYqX2DN/jA= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=nGHzwTtz; spf=pass (imf12.hostedemail.com: domain of luto@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664905602; a=rsa-sha256; cv=none; b=xkKZi2iIoqkZM9GZbo6V4zzc+7hkvh8ireldMt8Z73iRNcyLxSMEUmkDEAO2HfCu7d8nhE tKWL53gMCUGUIPG1UbRA0EkwToB+v9I6YtjcQXeDu+UzPBi0Rln12nOfZwotgxozIgVZRh KOwGvO65FIuKTKgaJb4uu9EnxzYmfWM= X-Rspamd-Queue-Id: 5688240015 Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=nGHzwTtz; spf=pass (imf12.hostedemail.com: domain of luto@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspamd-Server: rspam06 X-Rspam-User: X-Stat-Signature: bmx7dws6h9hrrgrda8gwxiz1ngoqhigf X-HE-Tag: 1664905602-796725 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 Tue, Oct 4, 2022, at 9:12 AM, Edgecombe, Rick P wrote: > On Mon, 2022-10-03 at 16:21 -0700, Andy Lutomirski wrote: >> On 9/29/22 15:29, Rick Edgecombe wrote: >> > To handle stack overflows, applications can register a separate >> > signal alt >> > stack to use for the stack to handle signals. To handle shadow >> > stack >> > overflows the kernel can similarly provide the ability to have an >> > alt >> > shadow stack. >> >> >> The overall SHSTK mechanism has a concept of a shadow stack that is >> valid and not in use and a shadow stack that is in use. This is >> used, >> for example, by RSTORSSP. I would like to imagine that this serves >> a >> real purpose (presumably preventing two different threads from using >> the >> same shadow stack and thus corrupting each others' state). >> >> So maybe altshstk should use exactly the same mechanism. Either >> signal >> delivery should do the atomic very-and-mark-busy routine or >> registering >> the stack as an altstack should do it. >> >> I think your patch has this maybe 1/3 implemented > > I'm not following how it breaks down into 3 parts, so hopefully I'm not > missing something. We could do a software busy bit for the token at the > end of alt shstk though. It seems like a good idea. I didn't mean there were three parts. I just wild @&! guessed the amount of code written versus needed :) > > The busy-like bit in the RSTORSSP-type token is not called out as a > busy bit, but instead defined as reserved (must be 0) in some states. > (Note, it is different than the supervisor shadow stack format). Yea, > we could just probably use it like RSTORSSP does for this operation. > > Or just invent another new token format and stay away from bits marked > reserved. Then it wouldn't have to be atomic either, since userspace > couldn't use it. But userspace *can* use it by delivering a signal. I consider the scenario where two user threads set up the same altshstk and take signals concurrently to be about as dangerous and about as likely (under accidental or malicious conditions) as two user threads doing RSTORSSP at the same time. Someone at Intel thought the latter was a big deal, so maybe we should match its behavior.