[v4,03/39] x86/cpufeatures: Add CPU feature flags for shadow stacks

  From: Yu-cheng Yu <yu-cheng.yu@intel.com>

The Control-Flow Enforcement Technology contains two related features,
one of which is Shadow Stacks. Future patches will utilize this feature
for shadow stack support in KVM, so add a CPU feature flags for Shadow
Stacks (CPUID.(EAX=7,ECX=0):ECX[bit 7]).

To protect shadow stack state from malicious modification, the registers
are only accessible in supervisor mode. This implementation
context-switches the registers with XSAVES. Make X86_FEATURE_SHSTK depend
on XSAVES.

The shadow stack feature, enumerated by the CPUID bit described above,
encompasses both supervisor and userspace support for shadow stack. In
near future patches, only userspace shadow stack will be enabled. In
expectation of future supervisor shadow stack support, create a software
CPU capability to enumerate kernel utilization of userspace shadow stack
support. This will also allow for userspace shadow stack to be disabled,
while leaving the shadow stack hardware capability exposed in the cpuinfo
proc. This user shadow stack bit should depend on the HW "shstk"
capability and that logic will be implemented in future patches.

Tested-by: Pengfei Xu <pengfei.xu@intel.com>
Tested-by: John Allen <john.allen@amd.com>
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Co-developed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Cc: Kees Cook <keescook@chromium.org>
---

v3:
 - Add user specific shadow stack cpu cap (Andrew Cooper)
 - Drop reviewed-bys from Boris and Kees due to the above change.

v2:
 - Remove IBT reference in commit log (Kees)
 - Describe xsaves dependency using text from (Dave)

v1:
 - Remove IBT, can be added in a follow on IBT series.

Yu-cheng v25:
 - Make X86_FEATURE_IBT depend on X86_FEATURE_SHSTK.

 arch/x86/include/asm/cpufeatures.h       | 2 ++
 arch/x86/include/asm/disabled-features.h | 8 +++++++-
 arch/x86/kernel/cpu/cpuid-deps.c         | 1 +
 3 files changed, 10 insertions(+), 1 deletion(-)
  

On Fri, Dec 02, 2022 at 04:35:30PM -0800, Rick Edgecombe wrote:
> From: Yu-cheng Yu <yu-cheng.yu@intel.com>
> 
> The Control-Flow Enforcement Technology contains two related features,
> one of which is Shadow Stacks. Future patches will utilize this feature
> for shadow stack support in KVM, so add a CPU feature flags for Shadow
> Stacks (CPUID.(EAX=7,ECX=0):ECX[bit 7]).
> 
> To protect shadow stack state from malicious modification, the registers
> are only accessible in supervisor mode. This implementation
> context-switches the registers with XSAVES. Make X86_FEATURE_SHSTK depend
> on XSAVES.
> 
> The shadow stack feature, enumerated by the CPUID bit described above,
> encompasses both supervisor and userspace support for shadow stack. In
> near future patches, only userspace shadow stack will be enabled. In
> expectation of future supervisor shadow stack support, create a software
> CPU capability to enumerate kernel utilization of userspace shadow stack
> support. This will also allow for userspace shadow stack to be disabled,
> while leaving the shadow stack hardware capability exposed in the cpuinfo
> proc. This user shadow stack bit should depend on the HW "shstk"
> capability and that logic will be implemented in future patches.
> 
> Tested-by: Pengfei Xu <pengfei.xu@intel.com>
> Tested-by: John Allen <john.allen@amd.com>
> Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>

Reviewed-by: Kees Cook <keescook@chromium.org>
  

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?

Thx.
  

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".
  

On Wed, Dec 07, 2022 at 10:35:59PM +0000, Edgecombe, Rick P wrote:
> 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".

Hmm, I don't have a clear idea how guest shstk support should do so
maybe this is all way off but yeah, if the host supports CET - the
*hardware* feature - then you can use the same logic to support that in
a VM.

I.e., if the guest sees CET - i.e., HV has advertized it - then guest
kernel behaves exactly the same as on the host.

But it is likely I'm missing something more involved...

Thx.