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 D115DC433F5 for ; Tue, 31 May 2022 18:00:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 262B06B0072; Tue, 31 May 2022 14:00:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 215866B0073; Tue, 31 May 2022 14:00:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B6FC6B0074; Tue, 31 May 2022 14:00:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id F35A56B0072 for ; Tue, 31 May 2022 14:00:47 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id CA5803562F for ; Tue, 31 May 2022 18:00:47 +0000 (UTC) X-FDA: 79526803734.22.8F9DBF8 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) by imf19.hostedemail.com (Postfix) with ESMTP id 6DF311A004D for ; Tue, 31 May 2022 18:00:32 +0000 (UTC) Received: by mail-pf1-f172.google.com with SMTP id j6so13874132pfe.13 for ; Tue, 31 May 2022 11:00:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BbUxo4yAz2zldbWEi0GluCNfOnin3cth9gUswEAqzU8=; b=hynBTbzO9rYY0qHxLkPOCSAV7PkFkMuKMQVwaYDYARYuWnM9o4kW+6rxRIYdspG+DS J/rTMUxu4nnsZKopHh7CclvjRd+Z/b82662SEdMCD65Cd39uYVAGCiz7JRhBmcVVzQPI QDeGJ+IBQiVFYn6Kzx7UMnvT4azS4kAVvyImB+arcqQ6/pihcplCHDY3QyiTllbucoFN s+tofLkTZcKnWf2Wl+ZXzM76fOuLvkSS7kcLWWcadnYm+2q0cNkQYAh+4VhLz/wHaBTx Ih6Bha6yH+VQl9q2yp7SlKX2ZvfKv5svKSOuMRR/wSv5RH2t4xvwUmZLACrz2ZwjXtqJ w9IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BbUxo4yAz2zldbWEi0GluCNfOnin3cth9gUswEAqzU8=; b=R6iIi98o6Bd6o1qYvy8E8JSMgoOkTiwGjszPau0HC1BhfGHOoFltGNR+9PREqS4F0c QZzsbKJWHmkpsLslo9KWBLmpH/1XPKyDIcw1D/GL0ADhCYlnXErkC78KUNhIlvEc4zrR WYwR5ed7EGW3X8gmX+eT9u7eQbhyYAvq3yFEmMDZzZXEGG7FUcEtVYvSoef/ErcEbCz/ xhUnuXncrxfLGp4HPZcYBb/hsWfn+MXE7oYnlH7COhF0+7HOkIPT8gxNHqGMsN0J14uF /z6Y1hqM3CBKAUQsK1iANTiKVYA5FVoGgH6Am6gJFf3ROJK08dK30QxaFYSkUx66Z7+N cSqQ== X-Gm-Message-State: AOAM5334Hx/BgXhs9rzCWWpNDNP6BF6sFdOCDBqyYyK5dTvGNjoWAq2c yJcrKbhU0cmbZ1xyytVVVFUk3/bXv+mfSFb25mw= X-Google-Smtp-Source: ABdhPJw72huO/7ofZw41/IrdbsJVshRqpIuB7v6o/MbZmah6cvF05hc9Bj6ASGuXAbQ+cjixMHZrrtyd3POkZdxlnbM= X-Received: by 2002:a63:2ad6:0:b0:3f9:d9fa:2713 with SMTP id q205-20020a632ad6000000b003f9d9fa2713mr44235809pgq.512.1654020046159; Tue, 31 May 2022 11:00:46 -0700 (PDT) MIME-Version: 1.0 References: <05df964f-552e-402e-981c-a8bea11c555c@www.fastmail.com> <40a3500c-835a-60b0-15bf-40c6622ad013@kernel.org> <7c637f729e14f03d0df744568800fc986542e33d.camel@intel.com> In-Reply-To: <7c637f729e14f03d0df744568800fc986542e33d.camel@intel.com> From: "H.J. Lu" Date: Tue, 31 May 2022 11:00:10 -0700 Message-ID: Subject: Re: [PATCH 00/35] Shadow stacks for userspace To: "Edgecombe, Rick P" Cc: "rppt@kernel.org" , "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" , "bp@alien8.de" , "Lutomirski, Andy" , "Yang, Weijiang" , "arnd@arndb.de" , "Moreira, Joao" , "tglx@linutronix.de" , "x86@kernel.org" , "mike.kravetz@oracle.com" , "linux-doc@vger.kernel.org" , "john.allen@amd.com" , "dave.martin@arm.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" Content-Type: text/plain; charset="UTF-8" X-Rspam-User: Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=hynBTbzO; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of hjl.tools@gmail.com designates 209.85.210.172 as permitted sender) smtp.mailfrom=hjl.tools@gmail.com X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 6DF311A004D X-Stat-Signature: gie1g1c5m79gn47esdqrqfxrtbgzkscu X-HE-Tag: 1654020032-595780 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 Tue, May 31, 2022 at 10:34 AM Edgecombe, Rick P wrote: > > On Tue, 2022-05-31 at 19:36 +0300, Mike Rapoport wrote: > > > WRSS is a feature where you would usually want to lock it as > > > disabled, > > > but WRSS cannot be enabled if shadow stack is not enabled. Locking > > > shadow stack and WRSS off together doesn't have any security > > > benefits > > > in theory. so I'm thinking glibc doesn't need to do this. The > > > kernel > > > could even refuse to lock WRSS without shadow stack being enabled. > > > Could we avoid the extra ptrace functionality then? > > > > What I see for is that a program can support shadow stack, glibc > > enables > > shadow stack, does not enable WRSS and than calls > > > > arch_prctl(ARCH_X86_FEATURE_LOCK, > > LINUX_X86_FEATURE_SHSTK | LINUX_X86_FEATURE_WRSS); > > I see the logic is glibc will lock SHSTK|IBT if either is enabled in > the elf header. I guess that is why I didn't see the locking happening > for me, because my manual enablement test doesn't have either set in > the header. > > It can't see where that glibc knows about WRSS though... > > The glibc logic seems wrong to me also, because shadow stack or IBT > could be force-disabled via glibc tunables. I don't see why the elf > header bit should exclusively control the feature locking. Or why both > should be locked if only one is in the header. glibc locks SHSTK and IBT only if they are enabled at run-time. It doesn't enable/disable/lock WRSS at the moment. If WRSS can be enabled via arch_prctl at any time, we can't lock it. If WRSS should be locked early, how should it be enabled in application? Also can WRSS be enabled from a dlopened object? > > > > so that WRSS cannot be re-enabled. > > > > For the programs that do not support shadow stack, both SHSTK and > > WRSS are > > disabled, but still there is the same call to > > arch_prctl(ARCH_X86_FEATURE_LOCK, ...) and then neither shadow stack > > nor > > WRSS can be enabled. > > > > My original plan was to run CRIU with no shadow stack, enable shadow > > stack > > and WRSS in the restored tasks using arch_prct() and after the shadow > > stack > > contents is restored disable WRSS. > > > > Obviously, this didn't work with glibc I have :) > > Were you disabling shadow stack via glibc tunnable? Or was the elf > header marked for IBT? If it was a plain old binary, the code looks to > me like it should not lock any features. > > > > > On the bright side, having a ptrace call to unlock shadow stack and > > wrss > > allows running CRIU itself with shadow stack. > > > > Yea, having something working is really great. My only hesitancy is > that, per a discussion on the LAM patchset, we are going to make this > enabling API CET only (same semantics for though). I suppose the > locking API arch_prctl() could still be support other arch features, > but it might be a second CET only regset. It's not the end of the > world. > > I guess the other consideration is tieing CRIU to glibc peculiarities. > Like even if we fix glibc, then CRIU may not work with some other libc > or app that force disables for some weird reason. Is it supposed to be > libc-agnostic? > -- H.J.