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 A9A48C433FE for ; Mon, 28 Feb 2022 21:30:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A74F8D0002; Mon, 28 Feb 2022 16:30:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 131098D0001; Mon, 28 Feb 2022 16:30:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EEB8E8D0002; Mon, 28 Feb 2022 16:30:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0073.hostedemail.com [216.40.44.73]) by kanga.kvack.org (Postfix) with ESMTP id DC7538D0001 for ; Mon, 28 Feb 2022 16:30:49 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 8F7B818194D65 for ; Mon, 28 Feb 2022 21:30:49 +0000 (UTC) X-FDA: 79193483418.23.A13F3E8 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf21.hostedemail.com (Postfix) with ESMTP id 3A1AD1C0019 for ; Mon, 28 Feb 2022 21:30: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 dfw.source.kernel.org (Postfix) with ESMTPS id 7C29E6117C; Mon, 28 Feb 2022 21:30:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D9E4CC340F1; Mon, 28 Feb 2022 21:30:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646083846; bh=AM6TeTTQzrvCkefOt+QPZqOwQUTdBvNLhJX5phHONLQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GnBVmgo4+8bhttIsNW4CIKc/50E3eVPyAU3WPHvIbZFh526BGoJDDPu9euSQBUDKD Hqa0yD2zHl/5viZcYelhCVWRM+sSGX89helGbR2G+NGXJYs+5igCjCAg21SlRAQtDZ rLmwcFj0dsqhceZW4/xjGYZ2S/n/ZUup7B9zx22+H49wHPnutO4iwea5ckkuIJwsjj eXXNOQyW7txN+VuS5I09mUcPBI3iQcBIYWr/TRup9fbPGQxbfZB3wEiDs98vDtZ3Qb ucimmN+ZslCHwheAq1x9BrTHx3oXb0uPUMNIhWsbl1SNq+6FwFrtl+Y726NXn/lDXz 3V9QuTESvr1aA== Date: Mon, 28 Feb 2022 23:30:29 +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: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5a792e77-0072-4ded-9f89-e7fcc7f7a1d6@www.fastmail.com> X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 3A1AD1C0019 X-Stat-Signature: exxtckxc7ncf1gcdtm5k67kcuag3brzk Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GnBVmgo4; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf21.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org X-HE-Tag: 1646083848-893540 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 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. For synchronous use-case PTRACE_SETREGSET will be enough, the rest of the sigframe can be restored by other means. And with 'criu restore' there may be even no tracer by the time sigreturn is called. > --Andy -- Sincerely yours, Mike.