| Message ID | 20221203003606.6838-4-rick.p.edgecombe@intel.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Shadow stacks for userspace | expand |
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.
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 */ diff --git a/arch/x86/include/asm/disabled-features.h b/arch/x86/include/asm/disabled-features.h index c44b56f7ffba..7a2954a16cb7 100644 --- a/arch/x86/include/asm/disabled-features.h +++ b/arch/x86/include/asm/disabled-features.h @@ -99,6 +99,12 @@ # define DISABLE_TDX_GUEST (1 << (X86_FEATURE_TDX_GUEST & 31)) #endif +#ifdef CONFIG_X86_USER_SHADOW_STACK +#define DISABLE_USER_SHSTK 0 +#else +#define DISABLE_USER_SHSTK (1 << (X86_FEATURE_USER_SHSTK & 31)) +#endif + /* * Make sure to add features to the correct mask */ @@ -114,7 +120,7 @@ #define DISABLED_MASK9 (DISABLE_SGX) #define DISABLED_MASK10 0 #define DISABLED_MASK11 (DISABLE_RETPOLINE|DISABLE_RETHUNK|DISABLE_UNRET| \ - DISABLE_CALL_DEPTH_TRACKING) + DISABLE_CALL_DEPTH_TRACKING|DISABLE_USER_SHSTK) #define DISABLED_MASK12 0 #define DISABLED_MASK13 0 #define DISABLED_MASK14 0 diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c index d95221117129..c3e4e5246df9 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -79,6 +79,7 @@ static const struct cpuid_dep cpuid_deps[] = { { X86_FEATURE_XFD, X86_FEATURE_XSAVES }, { X86_FEATURE_XFD, X86_FEATURE_XGETBV1 }, { X86_FEATURE_AMX_TILE, X86_FEATURE_XFD }, + { X86_FEATURE_SHSTK, X86_FEATURE_XSAVES }, {} };