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: <63ea77f5d14739f8184ea51a4df939a58b4764ab.camel@intel.com>
Date:   Wed, 7 Dec 2022 22:35:59 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "bp@...en8.de" <bp@...en8.de>
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>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "Yu, Yu-cheng" <yu-cheng.yu@...el.com>,
        "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>,
        "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 v4 03/39] x86/cpufeatures: Add CPU feature flags for
 shadow stacks

On Wed, 2022-12-07 at 12:00 +0100, Borislav Petkov wrote:
> On Fri, Dec 02, 2022 at 04:35:30PM -0800, Rick Edgecombe wrote:
> > diff --git a/arch/x86/include/asm/cpufeatures.h
> > b/arch/x86/include/asm/cpufeatures.h
> > index 11a0e06362e4..aab7fa4104d7 100644
> > --- a/arch/x86/include/asm/cpufeatures.h
> > +++ b/arch/x86/include/asm/cpufeatures.h
> > @@ -307,6 +307,7 @@
> >   #define X86_FEATURE_SGX_EDECCSSA     (11*32+18) /* "" SGX
> > EDECCSSA user leaf function */
> >   #define X86_FEATURE_CALL_DEPTH               (11*32+19) /* ""
> > Call depth tracking for RSB stuffing */
> >   #define X86_FEATURE_MSR_TSX_CTRL     (11*32+20) /* "" MSR
> > IA32_TSX_CTRL (Intel) implemented */
> > +#define X86_FEATURE_USER_SHSTK               (11*32+21) /* Shadow
> > stack support for user mode applications */
> >   
> >   /* Intel-defined CPU features, CPUID level 0x00000007:1 (EAX),
> > word 12 */
> >   #define X86_FEATURE_AVX_VNNI         (12*32+ 4) /* AVX VNNI
> > instructions */
> > @@ -369,6 +370,7 @@
> >   #define X86_FEATURE_OSPKE            (16*32+ 4) /* OS Protection
> > Keys Enable */
> >   #define X86_FEATURE_WAITPKG          (16*32+ 5) /*
> > UMONITOR/UMWAIT/TPAUSE Instructions */
> >   #define X86_FEATURE_AVX512_VBMI2     (16*32+ 6) /* Additional
> > AVX512 Vector Bit Manipulation Instructions */
> > +#define X86_FEATURE_SHSTK            (16*32+ 7) /* Shadow Stack */
> >   #define X86_FEATURE_GFNI             (16*32+ 8) /* Galois Field
> > New Instructions */
> >   #define X86_FEATURE_VAES             (16*32+ 9) /* Vector AES */
> >   #define X86_FEATURE_VPCLMULQDQ               (16*32+10) /* Carry-
> > Less Multiplication Double Quadword */
> 
> What is the end goal here?
> 
> To have X86_FEATURE_KERNEL_SHSTK or so someday too?
> 
> If so, then the hardware bit X86_FEATURE_SHSTK should be hidden in
> /proc/cpuinfo, i.e.,
> 
> #define X86_FEATURE_SHSTK            (16*32+ 7) /* "" Shadow Stack
> hardware support */
> 
> note the "", otherwise you'll have people go:
> 
> "hey, I have "shstk" in /proc/cpuinfo on my machine. Why doesn't it
> do
> anything?"
> 
> Or am I misreading where this is headed?

Yes, the suggestion was to have one for kernel and one for user. But I
was also thinking about how KVM could hypothetically support shadow
stack in guests in the non !CONFIG_X86_USER_SHADOW_STACK case (it only
needs CET_U xsave support). So that configuration wouldn't expose
user_shstk and since KVM's guest feature support is retrieved
programmatically, it could be nice to have some hint for KVM users that
they could try. Maybe it's simpler to just tie KVM and host support
together though. I'll remove "shstk".

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ