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 89A1FC433F5 for ; Thu, 3 Mar 2022 19:41:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E43198D0002; Thu, 3 Mar 2022 14:41:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DF3A78D0001; Thu, 3 Mar 2022 14:41:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CBACA8D0002; Thu, 3 Mar 2022 14:41:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0223.hostedemail.com [216.40.44.223]) by kanga.kvack.org (Postfix) with ESMTP id BC2388D0001 for ; Thu, 3 Mar 2022 14:41:23 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 668F2A22F7 for ; Thu, 3 Mar 2022 19:41:23 +0000 (UTC) X-FDA: 79204094046.28.96AB5CB Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf31.hostedemail.com (Postfix) with ESMTP id BC00C20005 for ; Thu, 3 Mar 2022 19:41:22 +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 2F2ABB826B2; Thu, 3 Mar 2022 19:41:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0B140C340EF; Thu, 3 Mar 2022 19:41:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646336479; bh=HnIl+skYzj5iayObsog4Gwt5/mfT/IRPSSfVgeKmYz4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=X8uZsrLg1wS1ue15JXjIfxZfrIa5F6ODclaaSFiZyVkfNfMcHMXT3ZbuxvxL7Onx8 Jg3ctOHPmPbwyxM14NsFAMoQZDC94faFO3AnXRrbYnP5vExv6Pp6sqnuEEjRneOQi3 LYeiFVb5PPd9pZVQPx3LC5YuaO19KOL1EPs/TBf1MVY9gntS+Br+wUj2CKKhM1ENU0 IMfniBvcYagWlGE9YWSjJDj8z9mSsmy1ktQBYlVWdLbcK+stdWxDtvFncBv2sMDXAR PVmhc2UjgnYwP6/OD9BYsNZcmOKoLeuX5rTxEML3bz6tggMoY63Qjg//nwj605iKyU /9ENWwMajevMA== Date: Thu, 3 Mar 2022 21:40:57 +0200 From: Mike Rapoport To: Andy Lutomirski 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 Message-ID: References: <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> <05df964f-552e-402e-981c-a8bea11c555c@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <05df964f-552e-402e-981c-a8bea11c555c@www.fastmail.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: BC00C20005 X-Stat-Signature: s4sxoiccicchf3d4zb5mp4aajppyrazu Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=X8uZsrLg; spf=pass (imf31.hostedemail.com: domain of rppt@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspam-User: X-HE-Tag: 1646336482-859929 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 02:55:30PM -0800, Andy Lutomirski wrote: > > > 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. Ok, let me reiterate. We have a seized and stopped tracee, use PTRACE_CALL_FUNCTION_SIGFRAME to push a signal frame onto the tracee's stack so that sigreturn could use that frame, then set the tracee %rip to the function we'd like to call and then we PTRACE_CONT the tracee. Tracee continues to execute the parasite code that calls sigreturn to clean up and restore the tracee process. PTRACE_CALL_FUNCTION_SIGFRAME also pushes a restore token to the shadow stack, just like setup_rt_frame() does, so that sys_rt_sigreturn() won't bail out at restore_signal_shadow_stack(). The only thing that CRIU actually needs is to push a restore token to the shadow stack, so for us a ptrace call that does that would be ideal. -- Sincerely yours, Mike.