linux-kernel - Re: [PATCH v2 29/39] x86/cet/shstk: Support wrss for userspace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <33ee10b3d41bfa1f8cf03f87f1d13e565bea3120.camel@intel.com>
Date:   Thu, 6 Oct 2022 00:38:06 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "keescook@...omium.org" <keescook@...omium.org>,
        "Lutomirski, Andy" <luto@...nel.org>
CC:     "bsingharora@...il.com" <bsingharora@...il.com>,
        "hpa@...or.com" <hpa@...or.com>,
        "Syromiatnikov, Eugene" <esyr@...hat.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "rdunlap@...radead.org" <rdunlap@...radead.org>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "Eranian, Stephane" <eranian@...gle.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "fweimer@...hat.com" <fweimer@...hat.com>,
        "nadav.amit@...il.com" <nadav.amit@...il.com>,
        "jannh@...gle.com" <jannh@...gle.com>,
        "dethoma@...rosoft.com" <dethoma@...rosoft.com>,
        "kcc@...gle.com" <kcc@...gle.com>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        "bp@...en8.de" <bp@...en8.de>, "oleg@...hat.com" <oleg@...hat.com>,
        "hjl.tools@...il.com" <hjl.tools@...il.com>,
        "Yang, Weijiang" <weijiang.yang@...el.com>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "pavel@....cz" <pavel@....cz>, "arnd@...db.de" <arnd@...db.de>,
        "Moreira, Joao" <joao.moreira@...el.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mike.kravetz@...cle.com" <mike.kravetz@...cle.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "jamorris@...ux.microsoft.com" <jamorris@...ux.microsoft.com>,
        "john.allen@....com" <john.allen@....com>,
        "rppt@...nel.org" <rppt@...nel.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        "corbet@....net" <corbet@....net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
        "gorcunov@...il.com" <gorcunov@...il.com>
Subject: Re: [PATCH v2 29/39] x86/cet/shstk: Support wrss for userspace

On Mon, 2022-10-03 at 21:37 -0700, Kees Cook wrote:
> On Mon, Oct 03, 2022 at 04:00:36PM -0700, Andy Lutomirski wrote:
> > On 10/3/22 15:28, Kees Cook wrote:
> > > On Thu, Sep 29, 2022 at 03:29:26PM -0700, Rick Edgecombe wrote:
> > > > For the current shadow stack implementation, shadow stacks
> > > > contents easily
> > > > be arbitrarily provisioned with data.
> > > 
> > > I can't parse this sentence.
> > > 
> > > > This property helps apps protect
> > > > themselves better, but also restricts any potential apps that
> > > > may want to
> > > > do exotic things at the expense of a little security.
> > > 
> > > Is anything using this right now? Wouldn't thing be safer without
> > > WRSS?
> > > (Why can't we skip this patch?)
> > > 
> > 
> > So that people don't write programs that need either (shstk off) or
> > (shstk
> > on and WRSS on) and crash or otherwise fail on kernels that support
> > shstk
> > but don't support WRSS, perhaps?
> 
> Right, yes. I meant more "what programs currently need WRSS to
> operate
> under shstk? (And what is it that they are doing that needs it?)"
> 
> All is see currently is compiler self-tests and emulators using it?
> 
https://codesearch.debian.net/search?q=%5Cb%28wrss%7CWRSS%29%5Cb&literal=0&perpkg=1

Most apps that weren't just automatically compiled haven't had
implementation effort yet. (of course glibc has had a bunch) I hope we
would see more of that when we finally get it upstream. So I think a
better question is, how many apps will need WRSS when they go to enable
shadow stack. I'm thinking the answer must be some and it could be nice
to catch them when they first investigate enabling it.

But yes, except for Mike's CRIU branch, there aren't any programs that
use it today, and we could drop it for a first implementation. I don't
see it as something that would only make things less safe though. It
just lets apps that can't easily work within the stricter shadow stack
environment, at least get access to a weaker but still beneficial one.

Kees, did you catch that it can be locked off while enabling shadow
stack?