linux-kernel - Re: [PATCH v6 28/41] x86: Introduce userspace API for shadow stack

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]

Date:   Fri, 24 Feb 2023 18:37:57 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "bp@...en8.de" <bp@...en8.de>
CC:     "david@...hat.com" <david@...hat.com>,
        "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>,
        "keescook@...omium.org" <keescook@...omium.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>,
        "pavel@....cz" <pavel@....cz>, "oleg@...hat.com" <oleg@...hat.com>,
        "hjl.tools@...il.com" <hjl.tools@...il.com>,
        "Yang, Weijiang" <weijiang.yang@...el.com>,
        "Lutomirski, Andy" <luto@...nel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "Schimpe, Christina" <christina.schimpe@...el.com>,
        "mike.kravetz@...cle.com" <mike.kravetz@...cle.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "debug@...osinc.com" <debug@...osinc.com>,
        "jamorris@...ux.microsoft.com" <jamorris@...ux.microsoft.com>,
        "john.allen@....com" <john.allen@....com>,
        "rppt@...nel.org" <rppt@...nel.org>,
        "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
        "mingo@...hat.com" <mingo@...hat.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 v6 28/41] x86: Introduce userspace API for shadow stack

On Fri, 2023-02-24 at 13:20 +0100, Borislav Petkov wrote:
> On Sat, Feb 18, 2023 at 01:14:20PM -0800, Rick Edgecombe wrote:
> > diff --git a/arch/x86/include/uapi/asm/prctl.h
> > b/arch/x86/include/uapi/asm/prctl.h
> > index 500b96e71f18..b2b3b7200b2d 100644
> > --- a/arch/x86/include/uapi/asm/prctl.h
> > +++ b/arch/x86/include/uapi/asm/prctl.h
> > @@ -20,4 +20,10 @@
> >   #define ARCH_MAP_VDSO_32             0x2002
> >   #define ARCH_MAP_VDSO_64             0x2003
> >   
> > +/* Don't use 0x3001-0x3004 because of old glibcs */
> 
> So where is this all new interface to userspace programs documented? 

In the first patch:

https://lore.kernel.org/lkml/20230218211433.26859-2-rick.p.edgecombe@intel.com/

Then some more documentation is added about ARCH_SHSTK_UNLOCK and
ARCH_SHSTK_STATUS (which are for CRIU) in those patches.

> Do
> we have an agreement with all the involved parties that this is how
> we're going to support shadow stacks and that this is what userspace
> should do?
> 
> I'd like to avoid one more fiasco with glibc etc here...

There are glibc patches prepared by HJ to use the new interface and
it's my understanding that he has discussed the changes with the other
glibc folks. Those glibc patches are used for testing these kernel
patches, but will not get upstream until the kernel patches to avoid
repeating the past problems. So I think it's as prepared as it can be.

One future thing that might come up... Glibc has this mode called
"permissive mode". When glibc is configured this way (compile time or
env var), it is supposed to disable shadow stack when dlopen()ing any
DSO that doesn't have the shadow stack elf header bit. The problem is,
it doesn't really work as intended. It only turns off shadow stack for
the calling thread, leaving the other threads free to call into the DSO
with shadow stack enabled. It's not clear yet if they are going to be
able to fix it in userspace. So this prompted some thinking of if there
could be an additional kernel mode to help glibc in this scenario. But
for non-permissive mode, glibc is queued up to use the interface as is.