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 4C78EC4332F for ; Tue, 8 Feb 2022 16:17:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A30546B0073; Tue, 8 Feb 2022 11:17:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9DDB26B0075; Tue, 8 Feb 2022 11:17:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 87E396B0078; Tue, 8 Feb 2022 11:17:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0227.hostedemail.com [216.40.44.227]) by kanga.kvack.org (Postfix) with ESMTP id 74E3A6B0073 for ; Tue, 8 Feb 2022 11:17:48 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 3711A181FA8D8 for ; Tue, 8 Feb 2022 16:17:48 +0000 (UTC) X-FDA: 79120118616.27.3DD88CA Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf29.hostedemail.com (Postfix) with ESMTP id A6603120007 for ; Tue, 8 Feb 2022 16:17:47 +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 ams.source.kernel.org (Postfix) with ESMTPS id BDBA5B81AF1; Tue, 8 Feb 2022 16:17:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1AF73C340EF; Tue, 8 Feb 2022 16:17:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1644337064; bh=jC6VMA8Sjd8HqhTCuSTd/fKRie9Nid3LAIoupAVCfTE=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=mFWGq8uAmEYrM4KqTeIPAKdvUJpkRPXpSvPv8XwE3fiYaMXlMUbLu1WwQN7AL2xGb sRRyeogXF566C+wrWX7L/PCPdoQHFZDwjv5ixiTClH+JX8n/SumavGgUi2JPTvhf4u HJTpMglX6kmleSRSkZe4HeCXS6JBz+W54bs7q63PRyQr6RsP2v2sFEEji+dZaB6fTc xcBN3abEqZKglPSQac6tasuTziU0eEtpsXc3cWYsGH6OT8JFTgcB1G9DOClNQ/TW2G Kl8BnawvDjkNfaLgLHml0AvcTfTcpLopAz/VZVvWPbY10IQhaYYyxsAs1XP5RFQ2+e tnzvW+xcodPhA== Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id C69D527C0054; Tue, 8 Feb 2022 11:17:41 -0500 (EST) Received: from imap48 ([10.202.2.98]) by compute5.internal (MEProxy); Tue, 08 Feb 2022 11:17:41 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrheejgdekfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedftehnugih ucfnuhhtohhmihhrshhkihdfuceolhhuthhosehkvghrnhgvlhdrohhrgheqnecuggftrf grthhtvghrnheptdfhheettddvtedvtedugfeuuefhtddugedvleevleefvdetleffgfef vdekgeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh eprghnugihodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeiudekheei fedvqddvieefudeiiedtkedqlhhuthhopeepkhgvrhhnvghlrdhorhhgsehlihhnuhigrd hluhhtohdruhhs X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7B8AA21E0073; Tue, 8 Feb 2022 11:17:40 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4748-g31a5b5f50e-fm-cal2020-20220204.001-g31a5b5f5 Mime-Version: 1.0 Message-Id: In-Reply-To: <87mtj1vh50.ffs@tglx> References: <87fsozek0j.ffs@tglx> <3421da7fc8474b6db0e265b20ffd28d0@AcuMS.aculab.com> <9f948745435c4c9273131146d50fe6f328b91a78.camel@intel.com> <6ba06196-0756-37a4-d6c4-2e47e6601dcd@kernel.org> <87mtj1vh50.ffs@tglx> Date: Tue, 08 Feb 2022 08:15:12 -0800 From: "Andy Lutomirski" To: "Thomas Gleixner" , "Rick P Edgecombe" , "H.J. Lu" , "David Laight" , "Adrian Reber" , "Cyrill Gorcunov" , "Eugene Syromiatnikov" , "Dmitry Safonov" <0x7f454c46@gmail.com> Cc: "Balbir Singh" , "H. Peter Anvin" , "Peter Zijlstra (Intel)" , "Randy Dunlap" , "Kees Cook" , "Eranian, Stephane" , "Kirill A. Shutemov" , "Dave Hansen" , "linux-mm@kvack.org" , "Florian Weimer" , "Nadav Amit" , "Jann Horn" , "kcc@google.com" , "linux-arch@vger.kernel.org" , "Pavel Machek" , "Oleg Nesterov" , "Weijiang Yang" , "Borislav Petkov" , "Arnd Bergmann" , "Moreira, Joao" , "Mike Kravetz" , "the arch/x86 maintainers" , "linux-doc@vger.kernel.org" , "Dave Martin" , "john.allen@amd.com" , "Ingo Molnar" , "Shankar, Ravi V" , "Jonathan Corbet" , "Linux Kernel Mailing List" , "Linux API" , "Cyrill Gorcunov" Subject: Re: [PATCH 00/35] Shadow stacks for userspace Content-Type: text/plain X-Rspamd-Server: rspam11 X-Rspam-User: X-Stat-Signature: wn8zk9uinj5wyhufiayk71g3njmabgs3 Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=mFWGq8uA; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf29.hostedemail.com: domain of luto@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=luto@kernel.org X-Rspamd-Queue-Id: A6603120007 X-HE-Tag: 1644337067-470032 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, Feb 8, 2022, at 1:31 AM, Thomas Gleixner wrote: > On Mon, Feb 07 2022 at 17:31, Andy Lutomirski wrote: >> So this leaves altshadowstack. If we want to allow userspace to handle >> a shstk overflow, I think we need altshadowstack. And I can easily >> imagine signal handling in a coroutine or user-threading evironment (Go? >> UMCG or whatever it's called?) wanting this. As noted, this obnoxious >> Andy person didn't like putting any shstk-related extensions in the FPU >> state. >> >> For better or for worse, altshadowstack is (I think) fundamentally a new >> API. No amount of ucontext magic is going to materialize an entire >> shadow stack out of nowhere when someone calls sigaltstack(). So the >> questions are: should we support altshadowstack from day one and, if so, >> what should it look like? > > I think we should support them from day one. > >> So I don't have a complete or even almost complete design in mind, but I >> think we do need to make a conscious decision either to design this >> right or to skip it for v1. > > Skipping it might create a fundamental design fail situation as it might > require changes to the shadow stack signal handling in general which > becomes a nightmare once a non-altstack API is exposed. It would also expose a range of kernels in which shstk is on but programs that want altshadowstack don't have it. That would be annoying. > >> As for CRIU, I don't think anyone really expects a new kernel, running >> new userspace that takes advantage of features in the new kernel, to >> work with old CRIU. > > Yes, CRIU needs updates, but what ensures that CRIU managed user space > does not use SHSTK if CRIU is not updated yet? In some sense this is like any other feature. If a program uses timerfd but CRIU doesn't support timerfd, then it won't work. SHSTK is a bit unique because it's likely that all programs on a system will start using it all at once.