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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A984C433EF for ; Tue, 8 Feb 2022 16:17:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1382952AbiBHQRs (ORCPT ); Tue, 8 Feb 2022 11:17:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236852AbiBHQRr (ORCPT ); Tue, 8 Feb 2022 11:17:47 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2B3FFC061576 for ; Tue, 8 Feb 2022 08:17:47 -0800 (PST) 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 D637BB81BDD for ; Tue, 8 Feb 2022 16:17:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 17AF6C004E1; 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 Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org 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.