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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 09424C433EF for ; Mon, 7 Feb 2022 07:32:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234082AbiBGHaG (ORCPT ); Mon, 7 Feb 2022 02:30:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33002 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232738AbiBGH3M (ORCPT ); Mon, 7 Feb 2022 02:29:12 -0500 X-Greylist: delayed 540 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Sun, 06 Feb 2022 23:29:09 PST Received: from rhlx01.hs-esslingen.de (rhlx01.hs-esslingen.DE [IPv6:2001:7c0:700::10]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 93C13C043181; Sun, 6 Feb 2022 23:29:09 -0800 (PST) Received: by rhlx01.hs-esslingen.de (Postfix, from userid 1203) id 39F2529B540F; Mon, 7 Feb 2022 08:20:02 +0100 (CET) Date: Mon, 7 Feb 2022 08:20:02 +0100 From: Adrian Reber To: Mike Rapoport Cc: Rick Edgecombe , x86@kernel.org, "H . Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H . J . Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V . Shankar" , Dave Martin , Weijiang Yang , "Kirill A . Shutemov" , joao.moreira@intel.com, John Allen , kcc@google.com, eranian@google.com, Andrei Vagin , Dmitry Safonov <0x7f454c46@gmail.com> Subject: Re: [PATCH 00/35] Shadow stacks for userspace Message-ID: References: <20220130211838.8382-1-rick.p.edgecombe@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Url: X-Operating-System: Linux (5.15.12-200.fc35.x86_64) X-Load-Average: 2.46 2.60 2.63 X-Unexpected: The Spanish Inquisition X-GnuPG-Key: gpg --recv-keys D3C4906A Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Feb 06, 2022 at 08:42:03PM +0200, Mike Rapoport wrote: > (added more CRIU people) Thanks, Mike. > On Sun, Jan 30, 2022 at 01:18:03PM -0800, Rick Edgecombe wrote: > > This is a slight reboot of the userspace CET series. I will be taking over the > > series from Yu-cheng. Per some internal recommendations, I’ve reset the version > > number and am calling it a new series. Hopefully, it doesn’t cause confusion. > > > > The new plan is to upstream only userspace Shadow Stack support at this point. > > IBT can follow later, but for now I’ll focus solely on the most in-demand and > > widely available (with the feature on AMD CPUs now) part of CET. > > > > I thought as part of this reset, it might be useful to more fully write-up the > > design and summarize the history of the previous CET series. So this slightly > > long cover letter does that. The "Updates" section has the changes, if anyone > > doesn't want the history. [...] > > CRIU Support > > ------------ > > In the past there was some speculation on the mailing list about > > whether CRIU would need to be taught about CET. It turns out, it does. > > The first issue hit is that CRIU calls sigreturn directly from its > > “parasite code” that it injects into the dumper process. This violates > > this shadow stack implementation’s protection that intends to prevent > > attackers from doing this. > > > > With so many packages already enabled with shadow stack, there is > > probably desire to make it work seamlessly. But in the meantime if > > distros want to support shadow stack and CRIU, users could manually > > disabled shadow stack via “GLIBC_TUNABLES=glibc.cpu.x86_shstk=off” for > > a process they will wants to dump. It’s not ideal. > > > > I’d like to hear what people think about having shadow stack in the > > kernel without this resolved. Nothing would change for any users until > > they enable shadow stack in the kernel and update to a glibc configured > > with CET. Should CRIU userspace be solved before kernel support? >From the CRIU side I can say that I would definitely like to see this resolved. CRIU just went through a similar exercise with rseq() being enabled in glibc and CI broke all around for us and other projects relying on CRIU. Although rseq() was around for a long time we were not aware of it but luckily 5.13 introduced a way to handle it for CRIU with ptrace. An environment variable existed but did not really help when CRIU is called somewhere in the middle of the container software stack. >From my point of view a solution not involving an environment variable would definitely be preferred. Adrian