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 54455C433F5 for ; Tue, 8 Feb 2022 16:21:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9DCCF6B0073; Tue, 8 Feb 2022 11:21:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 98B876B0075; Tue, 8 Feb 2022 11:21:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 804A56B0078; Tue, 8 Feb 2022 11:21:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0199.hostedemail.com [216.40.44.199]) by kanga.kvack.org (Postfix) with ESMTP id 7152A6B0073 for ; Tue, 8 Feb 2022 11:21:49 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 1B7C78249980 for ; Tue, 8 Feb 2022 16:21:49 +0000 (UTC) X-FDA: 79120128738.24.E6F95EA Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf05.hostedemail.com (Postfix) with ESMTP id 86698100002 for ; Tue, 8 Feb 2022 16:21:48 +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 76DBFB81C12; Tue, 8 Feb 2022 16:21:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8F00C340EC; 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 X-Rspamd-Queue-Id: 86698100002 X-Stat-Signature: ey71osbyojgsh4895bjmfpqptikxqfz3 X-Rspam-User: Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=SYdXu170; spf=pass (imf05.hostedemail.com: domain of luto@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspamd-Server: rspam05 X-HE-Tag: 1644337308-987578 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: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.