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 DADB6C433EF for ; Mon, 7 Mar 2022 18:57:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 443B58D0002; Mon, 7 Mar 2022 13:57:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3F32D8D0001; Mon, 7 Mar 2022 13:57:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2BC408D0002; Mon, 7 Mar 2022 13:57:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0040.hostedemail.com [216.40.44.40]) by kanga.kvack.org (Postfix) with ESMTP id 1F0578D0001 for ; Mon, 7 Mar 2022 13:57:11 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id CC067A79B0 for ; Mon, 7 Mar 2022 18:57:10 +0000 (UTC) X-FDA: 79218497820.16.971F5E5 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf04.hostedemail.com (Postfix) with ESMTP id 2F0F04000B for ; Mon, 7 Mar 2022 18:57:10 +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 747FAB81678; Mon, 7 Mar 2022 18:57:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9316CC340E9; Mon, 7 Mar 2022 18:56:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646679427; bh=kzPVR0Ts7EvL4cw43owr5qE2dp0dCtf1msIC/h6ja3s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hWt3NTUbKn9a8SzZ7LbBwKtKZCBQX3n8AciKZPGl1KpM2+i7OpUqh8VWt11+/jsNp KjxrMVQFwaVZyyh0sO2G8Klttr+Je2FWqjrNV3OrvR1V5893sxrksMVjYjNn2kWEox oITR2QtoXvgaoFUOtKuliF7ce1I4JjDomW4yS5EzHMhBbJdJTG8osUKLmzQbPzk5Ih 33mRGl8VIswmhVlNEivsIZEjlV1PMnRmuQrBCDPuyg33dWVBmOBF5pE+WPKkcMW4Mn JKkGQVk3mWdVACaEHCjPK9n8iC9rXLc6J49S2tDo6cfdt9MeWkvkdTQkTpv6caMSoQ kMvttHPSMcGEA== Date: Mon, 7 Mar 2022 20:56:44 +0200 From: Mike Rapoport To: Andy Lutomirski Cc: "Edgecombe, Rick P" , "bsingharora@gmail.com" , "hpa@zytor.com" , "Syromiatnikov, Eugene" , "peterz@infradead.org" , "rdunlap@infradead.org" , "keescook@chromium.org" , "0x7f454c46@gmail.com" <0x7f454c46@gmail.com>, "Eranian, Stephane" , "kirill.shutemov@linux.intel.com" , "dave.hansen@linux.intel.com" , "linux-mm@kvack.org" , "adrian@lisas.de" , "fweimer@redhat.com" , "nadav.amit@gmail.com" , "jannh@google.com" , "avagin@gmail.com" , "kcc@google.com" , "linux-arch@vger.kernel.org" , "pavel@ucw.cz" , "oleg@redhat.com" , "hjl.tools@gmail.com" , "bp@alien8.de" , "linux-doc@vger.kernel.org" , "arnd@arndb.de" , "Moreira, Joao" , "tglx@linutronix.de" , "mike.kravetz@oracle.com" , "x86@kernel.org" , "Yang, Weijiang" , "dave.martin@arm.com" , "john.allen@amd.com" , "mingo@redhat.com" , "Hansen, Dave" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "gorcunov@gmail.com" , "Shankar, Ravi V" , "linux-api@vger.kernel.org" Subject: Re: [PATCH 00/35] Shadow stacks for userspace Message-ID: References: <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> <40a3500c-835a-60b0-15bf-40c6622ad013@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40a3500c-835a-60b0-15bf-40c6622ad013@kernel.org> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 2F0F04000B X-Stat-Signature: 4aswt17b6ufycjk9d33xsjkrjf3hzbf8 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=hWt3NTUb; spf=pass (imf04.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-HE-Tag: 1646679430-362700 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 Fri, Mar 04, 2022 at 11:13:19AM -0800, Andy Lutomirski wrote: > On 3/3/22 17:30, Edgecombe, Rick P wrote: > > On Thu, 2022-03-03 at 15:00 -0800, Andy Lutomirski wrote: > > > > > 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. > > > > I guess pushing a token to the shadow stack could be done like GDB does > > calls, with just the basic CET ptrace support. So do we even need a > > specific push token operation? I've tried to follow gdb CET push implementation, but got lost. What is "basic CET ptrace support"? I don't see any ptrace changes in this series. > > I suppose if CRIU already used some kernel encapsulation of a seized > > call/return operation it would have been easier to make CRIU work with > > the introduction of CET. But the design of CRIU seems to be to have the > > kernel expose just enough and then tie it all together in userspace. > > > > Andy, did you have any other usages for PTRACE_CALL_FUNCTION in mind? I > > couldn't find any other CRIU-like users of sigreturn in the debian > > source search (but didn't read all 819 pages that come up with > > "sigreturn"). It seemed to be mostly seccomp sandbox references. > > I don't see a benefit compelling enough to justify the added complexity, > given that existing mechanisms can do it. > > The sigframe thing, OTOH, seems genuinely useful if CRIU would actually use > it to save the full register state. Generating a signal frame from scratch > is a pain. That being said, if CRIU isn't excited, then don't bother. CRIU is excited :) I just was looking for the minimal possible interface that will allow us to call sigreturn. Rick is right and CRIU does try to expose as little as possible and handle the pain in the userspace. The SIGFRAME approach is indeed very helpful, especially if we can make it work on other architectures eventually. -- Sincerely yours, Mike.