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 16DA0C433EF for ; Mon, 7 Feb 2022 07:20:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 732CF6B007D; Mon, 7 Feb 2022 02:20:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E4056B007E; Mon, 7 Feb 2022 02:20:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5AAFC6B0080; Mon, 7 Feb 2022 02:20:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0066.hostedemail.com [216.40.44.66]) by kanga.kvack.org (Postfix) with ESMTP id 4BF2E6B007D for ; Mon, 7 Feb 2022 02:20:10 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E7AFC8249980 for ; Mon, 7 Feb 2022 07:20:09 +0000 (UTC) X-FDA: 79115134938.13.9C722BF Received: from rhlx01.hs-esslingen.de (rhlx01.hs-esslingen.de [129.143.116.10]) by imf08.hostedemail.com (Postfix) with ESMTP id F13BE160003 for ; Mon, 7 Feb 2022 07:20:08 +0000 (UTC) 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 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 X-Rspamd-Queue-Id: F13BE160003 X-Rspam-User: nil Authentication-Results: imf08.hostedemail.com; dkim=none; spf=none (imf08.hostedemail.com: domain of adrian@rhlx01.hs-esslingen.de has no SPF policy when checking 129.143.116.10) smtp.mailfrom=adrian@rhlx01.hs-esslingen.de; dmarc=none X-Stat-Signature: tyhqq35usrfep7hmt9oc6xcgxziecboi X-Rspamd-Server: rspam08 X-HE-Tag: 1644218408-673615 Content-Transfer-Encoding: quoted-printable 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 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=20 > > series from Yu-cheng. Per some internal recommendations, I=E2=80=99ve= reset the version > > number and am calling it a new series. Hopefully, it doesn=E2=80=99t = cause confusion. > >=20 > > The new plan is to upstream only userspace Shadow Stack support at th= is point.=20 > > IBT can follow later, but for now I=E2=80=99ll focus solely on the mo= st in-demand and > > widely available (with the feature on AMD CPUs now) part of CET. > >=20 > > I thought as part of this reset, it might be useful to more fully wri= te-up the=20 > > design and summarize the history of the previous CET series. So this = slightly > > long cover letter does that. The "Updates" section has the changes, i= f anyone > > doesn't want the history. [...] > > CRIU Support > > ------------ > > In the past there was some speculation on the mailing list about=20 > > whether CRIU would need to be taught about CET. It turns out, it doe= s.=20 > > The first issue hit is that CRIU calls sigreturn directly from its=20 > > =E2=80=9Cparasite code=E2=80=9D that it injects into the dumper proc= ess. This violates > > this shadow stack implementation=E2=80=99s protection that intends t= o prevent > > attackers from doing this. > >=20 > > With so many packages already enabled with shadow stack, there is=20 > > probably desire to make it work seamlessly. But in the meantime if=20 > > distros want to support shadow stack and CRIU, users could manually=20 > > disabled shadow stack via =E2=80=9CGLIBC_TUNABLES=3Dglibc.cpu.x86_sh= stk=3Doff=E2=80=9D for=20 > > a process they will wants to dump. It=E2=80=99s not ideal. > >=20 > > I=E2=80=99d like to hear what people think about having shadow stack= in the=20 > > kernel without this resolved. Nothing would change for any users unt= il=20 > > they enable shadow stack in the kernel and update to a glibc configu= red > > 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