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 C6F62C433FE for ; Mon, 28 Feb 2022 22:56:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 36CA98D0002; Mon, 28 Feb 2022 17:56:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 31C498D0001; Mon, 28 Feb 2022 17:56:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1BD538D0002; Mon, 28 Feb 2022 17:56:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0081.hostedemail.com [216.40.44.81]) by kanga.kvack.org (Postfix) with ESMTP id 0CC2C8D0001 for ; Mon, 28 Feb 2022 17:56:01 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id AFC9B8248D52 for ; Mon, 28 Feb 2022 22:56:00 +0000 (UTC) X-FDA: 79193698080.18.293FC9C Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf09.hostedemail.com (Postfix) with ESMTP id 04F20140006 for ; Mon, 28 Feb 2022 22:55:59 +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 735E9B8169D; Mon, 28 Feb 2022 22:55:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 118EAC340EE; Mon, 28 Feb 2022 22:55:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646088957; bh=IrKyR4KsaGy6ILEoSjvY+Pfikinwp5UgDQ/3sdpyfQg=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=JTti+7gOLMySTeqWwRBxm9JF/LxEc36hF/DllbnINKGysrNoAZbJLJCN29tzVQpEC OPBNdIDfbz1a4MXrk6S84RC/ZiOGeWwOxLpW2V9hRJc+e7F2oPRIOxlhmAfsR40EkZ Q2pS4vFDlD+ecf+evWmIf7r7ooWXN3k3Pfc74WjAyCK5yndZ0W3PF081gZa2AVB1LT qIfQUnlwqzaDII5e8dWe49KxurJ1CpD4xSdpKFvkS+qWBTA9snzhIQ6jB54mE10KcI jijFO4uIy/i+6CAtuUZ+BqilyatRAWqJ7H624wNXOLvWOzS4C5e8sn1XGZbRzI/A4w RX+lyfAqXFcag== Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id B3D1A27C0054; Mon, 28 Feb 2022 17:55:53 -0500 (EST) Received: from imap48 ([10.202.2.98]) by compute5.internal (MEProxy); Mon, 28 Feb 2022 17:55:53 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddruddtuddgtddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdetnhgu hicunfhuthhomhhirhhskhhifdcuoehluhhtoheskhgvrhhnvghlrdhorhhgqeenucggtf frrghtthgvrhhnpedthfehtedtvdetvdetudfgueeuhfdtudegvdelveelfedvteelfffg fedvkeegfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpegrnhguhidomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudduiedukeeh ieefvddqvdeifeduieeitdekqdhluhhtoheppehkvghrnhgvlhdrohhrgheslhhinhhugi drlhhuthhordhush X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2E51821E006E; Mon, 28 Feb 2022 17:55:52 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4778-g14fba9972e-fm-20220217.001-g14fba997 Mime-Version: 1.0 Message-Id: <05df964f-552e-402e-981c-a8bea11c555c@www.fastmail.com> In-Reply-To: References: <8f96c2a6-9c03-f97a-df52-73ffc1d87957@intel.com> <357664de-b089-4617-99d1-de5098953c80@www.fastmail.com> <8e36f20723ca175db49ed3cc73e42e8aa28d2615.camel@intel.com> <9d664c91-2116-42cc-ef8d-e6d236de43d0@kernel.org> <5a792e77-0072-4ded-9f89-e7fcc7f7a1d6@www.fastmail.com> Date: Mon, 28 Feb 2022 14:55:30 -0800 From: "Andy Lutomirski" To: "Mike Rapoport" Cc: "Rick P Edgecombe" , "Cyrill Gorcunov" , "Balbir Singh" , "H. Peter Anvin" , "Eugene Syromiatnikov" , "Peter Zijlstra (Intel)" , "Randy Dunlap" , "Kees Cook" , "Dmitry Safonov" <0x7f454c46@gmail.com>, "Dave Hansen" , "Kirill A. Shutemov" , "Eranian, Stephane" , "linux-mm@kvack.org" , "Adrian Reber" , "Florian Weimer" , "Nadav Amit" , "Jann Horn" , "Andrei Vagin" , "linux-arch@vger.kernel.org" , "kcc@google.com" , "Borislav Petkov" , "Oleg Nesterov" , "H.J. Lu" , "Pavel Machek" , "linux-doc@vger.kernel.org" , "Arnd Bergmann" , "Moreira, Joao" , "Thomas Gleixner" , "Mike Kravetz" , "the arch/x86 maintainers" , "Weijiang Yang" , "Dave Martin" , "john.allen@amd.com" , "Ingo Molnar" , "Dave Hansen" , "Jonathan Corbet" , "Linux Kernel Mailing List" , "Linux API" , "Shankar, Ravi V" Subject: Re: [PATCH 00/35] Shadow stacks for userspace Content-Type: text/plain X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 04F20140006 X-Stat-Signature: c9t3axjugksj1kw1ckj6h95irx69iw58 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=JTti+7gO; spf=pass (imf09.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-HE-Tag: 1646088959-723399 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 Mon, Feb 28, 2022, at 1:30 PM, Mike Rapoport wrote: > On Mon, Feb 28, 2022 at 12:30:41PM -0800, Andy Lutomirski wrote: >> >> >> On Mon, Feb 28, 2022, at 12:27 PM, Mike Rapoport wrote: >> > On Wed, Feb 09, 2022 at 06:37:53PM -0800, Andy Lutomirski wrote: >> >> On 2/8/22 18:18, Edgecombe, Rick P wrote: >> >> > On Tue, 2022-02-08 at 20:02 +0300, Cyrill Gorcunov wrote: >> >> > >> > >> > Even with the current shadow stack interface Rick proposed, CRIU can restore >> > the victim using ptrace without any additional knobs, but we loose an >> > important ability to "self-cure" the victim from the parasite in case >> > anything goes wrong with criu control process. >> > >> > Moreover, the issue with backward compatibility is not with ptrace but with >> > sigreturn and it seems that criu is not its only user. >> >> So we need an ability for a tracer to cause the tracee to call a function >> and to return successfully. Apparently a gdb branch can already do this >> with shstk, and my PTRACE_CALL_FUNCTION_SIGFRAME should also do the >> trick. I don't see why we need a sigretur-but-dont-verify -- we just >> need this mechanism to create a frame such that sigreturn actually works. > > If I understand correctly, PTRACE_CALL_FUNCTION_SIGFRAME() injects a frame > into the tracee and makes the tracee call sigreturn. > I.e. the tracee is stopped and this is used pretty much as PTRACE_CONT or > PTRACE_SYSCALL. > > In such case this defeats the purpose of sigreturn in CRIU because it is > called asynchronously by the tracee when the tracer is about to detach or > even already detached. The intent of PTRACE_CALL_FUNCTION_SIGFRAME is push a signal frame onto the stack and call a function. That function should then be able to call sigreturn just like any normal signal handler. There should be no requirement that the tracer still be attached when this happens, although the code calling sigreturn still needs to be mapped. (Specifically, on modern arches, the user runtime is expected to provide a "restorer" that calls sigreturn. A hypotheticall PTRACE_CALL_FUNCTION_SIGFRAME would either need to call sigreturn directly or provide a restorer.)