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 C7A0DC433EF for ; Thu, 3 Mar 2022 23:00:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 308B58D0002; Thu, 3 Mar 2022 18:00:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B68D8D0001; Thu, 3 Mar 2022 18:00:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 17E5D8D0002; Thu, 3 Mar 2022 18:00:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0095.hostedemail.com [216.40.44.95]) by kanga.kvack.org (Postfix) with ESMTP id 09C018D0001 for ; Thu, 3 Mar 2022 18:00:48 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id A0FC818215F87 for ; Thu, 3 Mar 2022 23:00:47 +0000 (UTC) X-FDA: 79204596534.22.9A98143 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf26.hostedemail.com (Postfix) with ESMTP id D7474140015 for ; Thu, 3 Mar 2022 23:00:46 +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 C2DC2B82702 for ; Thu, 3 Mar 2022 23:00:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 02731C340FA for ; Thu, 3 Mar 2022 23:00:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646348443; bh=FYI/8Y1WBT4HzXcUE12f554+O6V/H3p/NTj/MzLSdWk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=RhvWiZYVlp++BwCcizt89hu5pgdJElz0scbJOueFJ0yWEPPBLhx9g1T/vbQl/3tfU 4qTC2jpnzyU2BE9mFOw+NWNi96HNxZgxpwSjYrQ7AsUF/jJwbkES/q3g/EotbwNfHH AZ+t4NAJ1qLFhyxWblkKo2ryFEhjeNmRs0bssg4zrQ8KreEjs7sffweK7TXVJneMvA sbxQ5lIJuj8piKnBlG+joJ45DBcEFupOi4auT4qtx0yDKmIkaz39USWQi/5e2FbTU5 isfYcwR/fgLZMROty95627RAHzGS/41Bcnh9Bknmxlm7kixg2aUZ6lwL5ZRHXCBsxG 4DFNrzq8zw8WA== Received: by mail-ed1-f48.google.com with SMTP id o1so7488350edc.3 for ; Thu, 03 Mar 2022 15:00:42 -0800 (PST) X-Gm-Message-State: AOAM533C2juhlURF0yY9ZI7jn0gksmkEDyB/6lNGf5HxNTUMrvpnO7xp Efu+MMi1abo11aWijw7+CTsoUIIDa3+55hQRv26cnA== X-Google-Smtp-Source: ABdhPJz3cl4jMqcvfSKVHunCPtaNdRheKNjy3rSm1wymcJSedk+TallQEQF6erOXFO+yao9Hp2Eo8ER04EB83dGMZ7o= X-Received: by 2002:a05:6402:2c6:b0:415:b06c:de71 with SMTP id b6-20020a05640202c600b00415b06cde71mr11466619edx.50.1646348441080; Thu, 03 Mar 2022 15:00:41 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: From: Andy Lutomirski Date: Thu, 3 Mar 2022 15:00:29 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 00/35] Shadow stacks for userspace To: Mike Rapoport Cc: Andy Lutomirski , 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" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: D7474140015 X-Stat-Signature: 488sxm3hp3of6xasiznwfbj478wgaf4k Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=RhvWiZYV; spf=pass (imf26.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-Rspam-User: X-HE-Tag: 1646348446-379162 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 Thu, Mar 3, 2022 at 11:43 AM Mike Rapoport wrote: > > 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(). That is the intent. > > 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. > That seems fine too. The main benefit of the SIGFRAME approach is that, AIUI, CRIU eventually constructs a signal frame anyway, and getting one ready-made seems plausibly helpful. But if it's not actually that useful, then there's no need to do it.