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 C9C88C433EF for ; Tue, 8 Feb 2022 16:21:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229597AbiBHQVx (ORCPT ); Tue, 8 Feb 2022 11:21:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50878 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1381331AbiBHQVs (ORCPT ); Tue, 8 Feb 2022 11:21:48 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AD01EC061579; Tue, 8 Feb 2022 08:21: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 6F0FCB81920; Tue, 8 Feb 2022 16:21:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E2A55C36AE3; Tue, 8 Feb 2022 16:21:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1644337305; bh=cUXMYwV3FsUsTmiMnq+uhwE47soE1KcN2fh5D+proTA=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=SYdXu170xBHHUjtWDtgioa8Qvsdmh617pUIz2hpTg+v6xiUUBB9OVj4a8ioygzGSP 5md+IpahrD5rW14xK8o5ixxtIgMCX9w5yp3ahVR5Xkp0ecGeXEWikrYFsV3WYAdPFa fWZpnU0b6YOjzCvjmMfapyOY1UFOnmLynludGChjdJwdDn/ueLf7pVoF0f3VJA+hb3 B04vO1/hRv36Sc0EGyp5VQyCrQXaMEbYHOk6eMIm0ewlX27cUByN14msoA5tJqGFcN B3CWrkbNnSd4NCxzzPk6sd/ksgmuWlhv+BkH8LYcbuBfNY1FL9hJlYse+7Rpcsfbjh GvHiWrTP8wwMA== Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id 73F7B27C005A; Tue, 8 Feb 2022 11:21:42 -0500 (EST) Received: from imap48 ([10.202.2.98]) by compute5.internal (MEProxy); Tue, 08 Feb 2022 11:21:42 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrheejgdekgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedftehnugih ucfnuhhtohhmihhrshhkihdfuceolhhuthhosehkvghrnhgvlhdrohhrgheqnecuggftrf grthhtvghrnheptdfhheettddvtedvtedugfeuuefhtddugedvleevleefvdetleffgfef vdekgeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh eprghnugihodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeiudekheei fedvqddvieefudeiiedtkedqlhhuthhopeepkhgvrhhnvghlrdhorhhgsehlihhnuhigrd hluhhtohdruhhs X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D580121E0073; Tue, 8 Feb 2022 11:21: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: <357664de-b089-4617-99d1-de5098953c80@www.fastmail.com> In-Reply-To: References: <20220130211838.8382-1-rick.p.edgecombe@intel.com> <8f96c2a6-9c03-f97a-df52-73ffc1d87957@intel.com> Date: Tue, 08 Feb 2022 08:21:20 -0800 From: "Andy Lutomirski" To: "Cyrill Gorcunov" , "Mike Rapoport" Cc: "Dave Hansen" , "Adrian Reber" , "Rick P Edgecombe" , "the arch/x86 maintainers" , "H. Peter Anvin" , "Thomas Gleixner" , "Ingo Molnar" , "Linux Kernel Mailing List" , linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, "Linux API" , "Arnd Bergmann" , "Balbir Singh" , "Borislav Petkov" , "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 (Intel)" , "Randy Dunlap" , "Shankar, Ravi V" , "Dave Martin" , "Weijiang Yang" , "Kirill A. Shutemov" , "Moreira, Joao" , "john.allen@amd.com" , "kcc@google.com" , "Eranian, Stephane" , "Andrei Vagin" , "Dmitry Safonov" <0x7f454c46@gmail.com> Subject: Re: [PATCH 00/35] Shadow stacks for userspace Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Tue, Feb 8, 2022, at 1:29 AM, Cyrill Gorcunov wrote: > On Tue, Feb 08, 2022 at 11:16:51AM +0200, Mike Rapoport wrote: >> >> > Any thoughts on how you would _like_ to see this resolved? >> >> Ideally, CRIU will need a knob that will tell the kernel/CET machinery >> where the next RET will jump, along the lines of >> restore_signal_shadow_stack() AFAIU. >> >> But such a knob will immediately reduce the security value of the entire >> thing, and I don't have good ideas how to deal with it :( > > Probably a kind of latch in the task_struct which would trigger off once > returt to a different address happened, thus we would be able to jump inside > paratite code. Of course such trigger should be available under proper > capability only. I'm not fully in touch with how parasite, etc works. Are we talking about save or restore? If it's restore, what exactly does CRIU need to do? Is it just that CRIU needs to return out from its resume code into the to-be-resumed program without tripping CET? Would it be acceptable for CRIU to require that at least one shstk slot be free at save time? Or do we need a mechanism to atomically switch to a completely full shadow stack at resume? Off the top of my head, a sigreturn (or sigreturn-like mechanism) that is intended for use for altshadowstack could safely verify a token on the altshdowstack, possibly compare to something in ucontext (or not -- this isn't clearly necessary) and switch back to the previous stack. CRIU could use that too. Obviously CRIU will need a way to populate the relevant stacks, but WRUSS can be used for that, and I think this is a fundamental requirement for CRIU -- CRIU restore absolutely needs a way to write the saved shadow stack data into the shadow stack. So I think the only special capability that CRIU really needs is WRUSS, and we need to wire that up anyway.