| Message ID | 20221104223604.29615-36-rick.p.edgecombe@intel.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Shadow stacks for userspace | expand |
On Fri, Nov 04, 2022 at 03:36:02PM -0700, Rick Edgecombe wrote: > From: Yu-cheng Yu <yu-cheng.yu@intel.com> > > Some applications (like GDB and CRIU) would like to tweak CET state via > ptrace. This allows for existing functionality to continue to work for > seized CET applications. Provide an interface based on the xsave buffer > format of CET, but filter unneeded states to make the kernel’s job > easier. > > There is already ptrace functionality for accessing xstate, but this > does not include supervisor xfeatures. So there is not a completely > clear place for where to put the CET state. Adding it to the user > xfeatures regset would complicate that code, as it currently shares > logic with signals which should not have supervisor features. > > Don’t add a general supervisor xfeature regset like the user one, > because it is better to maintain flexibility for other supervisor > xfeatures to define their own interface. For example, an xfeature may > decide not to expose all of it’s state to userspace. A lot of enum > values remain to be used, so just put it in dedicated CET regset. > > The only downside to not having a generic supervisor xfeature regset, > is that apps need to be enlightened of any new supervisor xfeature > exposed this way (i.e. they can’t try to have generic save/restore > logic). But maybe that is a good thing, because they have to think > through each new xfeature instead of encountering issues when new a new > supervisor xfeature was added. Per this argument this should not use the CET XSAVE format and CET name at all, because that conflates the situation vs IBT. Enabling that might not want to follow this precedent. > By adding a CET regset, it also has the effect of including the CET state > in a core dump, which could be useful for debugging. > > Inside the setter CET regset, filter out invalid state. Today this > includes states disallowed by the HW and states involving Indirect Branch > Tracking which the kernel does not currently support for usersapce. > > So this leaves three pieces of data that can be set, shadow stack > enablement, WRSS enablement and the shadow stack pointer. It is worth > noting that this is separate than enabling shadow stack via the > arch_prctl()s. Does this validate the SSP, when set, points to an actual valid SS page?
+ Christina On Tue, 2022-11-15 at 15:43 +0100, Peter Zijlstra wrote: > On Fri, Nov 04, 2022 at 03:36:02PM -0700, Rick Edgecombe wrote: > > From: Yu-cheng Yu <yu-cheng.yu@intel.com> > > > > Some applications (like GDB and CRIU) would like to tweak CET state > > via > > ptrace. This allows for existing functionality to continue to work > > for > > seized CET applications. Provide an interface based on the xsave > > buffer > > format of CET, but filter unneeded states to make the kernel’s job > > easier. > > > > There is already ptrace functionality for accessing xstate, but > > this > > does not include supervisor xfeatures. So there is not a completely > > clear place for where to put the CET state. Adding it to the user > > xfeatures regset would complicate that code, as it currently shares > > logic with signals which should not have supervisor features. > > > > Don’t add a general supervisor xfeature regset like the user one, > > because it is better to maintain flexibility for other supervisor > > xfeatures to define their own interface. For example, an xfeature > > may > > decide not to expose all of it’s state to userspace. A lot of enum > > values remain to be used, so just put it in dedicated CET regset. > > > > The only downside to not having a generic supervisor xfeature > > regset, > > is that apps need to be enlightened of any new supervisor xfeature > > exposed this way (i.e. they can’t try to have generic save/restore > > logic). But maybe that is a good thing, because they have to think > > through each new xfeature instead of encountering issues when new a > > new > > supervisor xfeature was added. > > Per this argument this should not use the CET XSAVE format and CET > name > at all, because that conflates the situation vs IBT. Enabling that > might > not want to follow this precedent. Hmm, we definitely need to be able to set the SSP. Christina, does GDB need anything else? I thought maybe toggling SHSTK_EN? So it might end up looking pretty much the same, and it would just be renamed and separated in concept. > > > By adding a CET regset, it also has the effect of including the CET > > state > > in a core dump, which could be useful for debugging. > > > > Inside the setter CET regset, filter out invalid state. Today this > > includes states disallowed by the HW and states involving Indirect > > Branch > > Tracking which the kernel does not currently support for usersapce. > > > > So this leaves three pieces of data that can be set, shadow stack > > enablement, WRSS enablement and the shadow stack pointer. It is > > worth > > noting that this is separate than enabling shadow stack via the > > arch_prctl()s. > > Does this validate the SSP, when set, points to an actual valid SS > page? No, but that situation is already possible and has to be handled anyway. Just unmap your shadow stack, and map whatever other type of memory at the same address without doing a call or ret. Then you will segfault at the first call or ret.
> + Christina > > On Tue, 2022-11-15 at 15:43 +0100, Peter Zijlstra wrote: > > On Fri, Nov 04, 2022 at 03:36:02PM -0700, Rick Edgecombe wrote: > > > From: Yu-cheng Yu <yu-cheng.yu@intel.com> > > > > > > Some applications (like GDB and CRIU) would like to tweak CET state > > > via ptrace. This allows for existing functionality to continue to > > > work for seized CET applications. Provide an interface based on the > > > xsave buffer format of CET, but filter unneeded states to make the > > > kernel’s job easier. > > > > > > There is already ptrace functionality for accessing xstate, but this > > > does not include supervisor xfeatures. So there is not a completely > > > clear place for where to put the CET state. Adding it to the user > > > xfeatures regset would complicate that code, as it currently shares > > > logic with signals which should not have supervisor features. > > > > > > Don’t add a general supervisor xfeature regset like the user one, > > > because it is better to maintain flexibility for other supervisor > > > xfeatures to define their own interface. For example, an xfeature > > > may decide not to expose all of it’s state to userspace. A lot of > > > enum values remain to be used, so just put it in dedicated CET > > > regset. > > > > > > The only downside to not having a generic supervisor xfeature > > > regset, is that apps need to be enlightened of any new supervisor > > > xfeature exposed this way (i.e. they can’t try to have generic > > > save/restore logic). But maybe that is a good thing, because they > > > have to think through each new xfeature instead of encountering > > > issues when new a new supervisor xfeature was added. > > > > Per this argument this should not use the CET XSAVE format and CET > > name at all, because that conflates the situation vs IBT. Enabling > > that might not want to follow this precedent. > > Hmm, we definitely need to be able to set the SSP. Christina, does GDB need > anything else? I thought maybe toggling SHSTK_EN? In addition to the SSP, we want to write the CET state. For instance for inferior calls, we want to reset the IBT bits. However, we won't write states that are disallowed by HW. Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
On Thu, Nov 17, 2022 at 12:25:16PM +0000, Schimpe, Christina wrote: > > + Christina > > > > On Tue, 2022-11-15 at 15:43 +0100, Peter Zijlstra wrote: > > > On Fri, Nov 04, 2022 at 03:36:02PM -0700, Rick Edgecombe wrote: > > > > From: Yu-cheng Yu <yu-cheng.yu@intel.com> > > > > > > > > Some applications (like GDB and CRIU) would like to tweak CET state > > > > via ptrace. This allows for existing functionality to continue to > > > > work for seized CET applications. Provide an interface based on the > > > > xsave buffer format of CET, but filter unneeded states to make the > > > > kernel’s job easier. > > > > > > > > There is already ptrace functionality for accessing xstate, but this > > > > does not include supervisor xfeatures. So there is not a completely > > > > clear place for where to put the CET state. Adding it to the user > > > > xfeatures regset would complicate that code, as it currently shares > > > > logic with signals which should not have supervisor features. > > > > > > > > Don’t add a general supervisor xfeature regset like the user one, > > > > because it is better to maintain flexibility for other supervisor > > > > xfeatures to define their own interface. For example, an xfeature > > > > may decide not to expose all of it’s state to userspace. A lot of > > > > enum values remain to be used, so just put it in dedicated CET > > > > regset. > > > > > > > > The only downside to not having a generic supervisor xfeature > > > > regset, is that apps need to be enlightened of any new supervisor > > > > xfeature exposed this way (i.e. they can’t try to have generic > > > > save/restore logic). But maybe that is a good thing, because they > > > > have to think through each new xfeature instead of encountering > > > > issues when new a new supervisor xfeature was added. > > > > > > Per this argument this should not use the CET XSAVE format and CET > > > name at all, because that conflates the situation vs IBT. Enabling > > > that might not want to follow this precedent. > > > > Hmm, we definitely need to be able to set the SSP. Christina, does GDB need > > anything else? I thought maybe toggling SHSTK_EN? > > In addition to the SSP, we want to write the CET state. For instance for inferior calls, > we want to reset the IBT bits. This is about Shadow Stack -- IBT is a completely different feature and not subject of this series. Also, wth is an inferior call?
On Thu, 2022-11-17 at 12:25 +0000, Schimpe, Christina wrote: > > Hmm, we definitely need to be able to set the SSP. Christina, does > > GDB need > > anything else? I thought maybe toggling SHSTK_EN? > > In addition to the SSP, we want to write the CET state. For instance > for inferior calls, > we want to reset the IBT bits. > However, we won't write states that are disallowed by HW. Sorry, I should have given more background. Peter is saying we should split the ptrace interface so that shadow stack and IBT are separate. They would also no longer necessarily mirror the CET_U MSR format. Instead the kernel would expose a kernel specific format that has the needed bits of shadow stack support. And a separate one later for IBT. So the question is what does shadow stack need to support for ptrace besides SSP? Is it only SSP? The other features are SHSTK_EN and WRSS_EN. It might actually be nice to keep how these bits get flipped more controlled (remove them from ptrace). It looks like CRIU didn't need them.
> On Thu, 2022-11-17 at 12:25 +0000, Schimpe, Christina wrote: > > > Hmm, we definitely need to be able to set the SSP. Christina, does > > > GDB need anything else? I thought maybe toggling SHSTK_EN? > > > > In addition to the SSP, we want to write the CET state. For instance > > for inferior calls, we want to reset the IBT bits. > > However, we won't write states that are disallowed by HW. > > Sorry, I should have given more background. Peter is saying we should split > the ptrace interface so that shadow stack and IBT are separate. > They would also no longer necessarily mirror the CET_U MSR format. > Instead the kernel would expose a kernel specific format that has the > needed bits of shadow stack support. And a separate one later for IBT. > > So the question is what does shadow stack need to support for ptrace > besides SSP? Is it only SSP? The other features are SHSTK_EN and WRSS_EN. > It might actually be nice to keep how these bits get flipped more controlled > (remove them from ptrace). It looks like CRIU didn't need them. > GDB currently reads the CET_U and SSP register. However, we don’t necessarily have to read EB_LEG_BITMAP_BASE. In addition to SSP, we want to write the bits for the IBT state machine (TRACKER and SUPPRESS). However, besides that GDB does not have to write anything else. Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
On Fri, 2022-11-18 at 16:21 +0000, Schimpe, Christina wrote: > > On Thu, 2022-11-17 at 12:25 +0000, Schimpe, Christina wrote: > > > > Hmm, we definitely need to be able to set the SSP. Christina, > > > > does > > > > GDB need anything else? I thought maybe toggling SHSTK_EN? > > > > > > In addition to the SSP, we want to write the CET state. For > > > instance > > > for inferior calls, we want to reset the IBT bits. > > > However, we won't write states that are disallowed by HW. > > > > Sorry, I should have given more background. Peter is saying we > > should split > > the ptrace interface so that shadow stack and IBT are separate. > > They would also no longer necessarily mirror the CET_U MSR format. > > Instead the kernel would expose a kernel specific format that has > > the > > needed bits of shadow stack support. And a separate one later for > > IBT. > > > > So the question is what does shadow stack need to support for > > ptrace > > besides SSP? Is it only SSP? The other features are SHSTK_EN and > > WRSS_EN. > > It might actually be nice to keep how these bits get flipped more > > controlled > > (remove them from ptrace). It looks like CRIU didn't need them. > > > > GDB currently reads the CET_U and SSP register. However, we don’t > necessarily have to read EB_LEG_BITMAP_BASE. > In addition to SSP, we want to write the bits for the IBT state > machine (TRACKER and SUPPRESS). > However, besides that GDB does not have to write anything else. Again, this is just about shadow stack. IBT will have a separate interface. So based on these comments, I'll change the interface in this patch to one for simply reading/writing SSP.
On Thu, 2022-11-17 at 15:14 +0100, Peter Zijlstra wrote:
> Also, wth is an inferior call?
I think it's the GDB functionality to make a call in the process being
debugged. So if you want to call something without an endbranch I
guess.
> On Thu, 2022-11-17 at 15:14 +0100, Peter Zijlstra wrote: > > Also, wth is an inferior call? > > I think it's the GDB functionality to make a call in the process being debugged. > So if you want to call something without an endbranch I guess. For inferior calls, GDB builds a dummy-frame to evaluate an expression: https://sourceware.org/gdb/onlinedocs/gdb/Calling.html Best Regards, Christina Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
On Thu, Nov 17, 2022 at 07:57:59PM +0000, Edgecombe, Rick P wrote: > On Thu, 2022-11-17 at 12:25 +0000, Schimpe, Christina wrote: > > > Hmm, we definitely need to be able to set the SSP. Christina, does > > > GDB need > > > anything else? I thought maybe toggling SHSTK_EN? > > > > In addition to the SSP, we want to write the CET state. For instance > > for inferior calls, > > we want to reset the IBT bits. > > However, we won't write states that are disallowed by HW. > > Sorry, I should have given more background. Peter is saying we should > split the ptrace interface so that shadow stack and IBT are separate. > They would also no longer necessarily mirror the CET_U MSR format. > Instead the kernel would expose a kernel specific format that has the > needed bits of shadow stack support. And a separate one later for IBT. > > So the question is what does shadow stack need to support for ptrace > besides SSP? Is it only SSP? The other features are SHSTK_EN and > WRSS_EN. It might actually be nice to keep how these bits get flipped > more controlled (remove them from ptrace). It looks like CRIU didn't > need them. CRIU reads CET_U with ptrace(PTRACE_GETREGSET, NT_X86_CET). It's done before the injection of the parasite. The value of SHSTK_EN is used then to detect if shadow stack is enabled and to setup victim's shadow stack for sigreturn.
On Mon, 2022-11-21 at 09:40 +0200, Mike Rapoport wrote: > On Thu, Nov 17, 2022 at 07:57:59PM +0000, Edgecombe, Rick P wrote: > > On Thu, 2022-11-17 at 12:25 +0000, Schimpe, Christina wrote: > > > > Hmm, we definitely need to be able to set the SSP. Christina, > > > > does > > > > GDB need > > > > anything else? I thought maybe toggling SHSTK_EN? > > > > > > In addition to the SSP, we want to write the CET state. For > > > instance > > > for inferior calls, > > > we want to reset the IBT bits. > > > However, we won't write states that are disallowed by HW. > > > > Sorry, I should have given more background. Peter is saying we > > should > > split the ptrace interface so that shadow stack and IBT are > > separate. > > They would also no longer necessarily mirror the CET_U MSR format. > > Instead the kernel would expose a kernel specific format that has > > the > > needed bits of shadow stack support. And a separate one later for > > IBT. > > > > So the question is what does shadow stack need to support for > > ptrace > > besides SSP? Is it only SSP? The other features are SHSTK_EN and > > WRSS_EN. It might actually be nice to keep how these bits get > > flipped > > more controlled (remove them from ptrace). It looks like CRIU > > didn't > > need them. > > > CRIU reads CET_U with ptrace(PTRACE_GETREGSET, NT_X86_CET). It's done > before the injection of the parasite. The value of SHSTK_EN is used > then to > detect if shadow stack is enabled and to setup victim's shadow stack > for > sigreturn. Hmm, can it read /proc/pid/status? It has some lines like this: x86_Thread_features: shstk wrss x86_Thread_features_locked: shstk wrss
On Mon, Nov 21, 2022 at 03:52:57PM +0000, Edgecombe, Rick P wrote: > On Mon, 2022-11-21 at 09:40 +0200, Mike Rapoport wrote: > > On Thu, Nov 17, 2022 at 07:57:59PM +0000, Edgecombe, Rick P wrote: > > > On Thu, 2022-11-17 at 12:25 +0000, Schimpe, Christina wrote: > > > > > Hmm, we definitely need to be able to set the SSP. Christina, > > > > > does > > > > > GDB need > > > > > anything else? I thought maybe toggling SHSTK_EN? > > > > > > > > In addition to the SSP, we want to write the CET state. For > > > > instance > > > > for inferior calls, > > > > we want to reset the IBT bits. > > > > However, we won't write states that are disallowed by HW. > > > > > > Sorry, I should have given more background. Peter is saying we > > > should > > > split the ptrace interface so that shadow stack and IBT are > > > separate. > > > They would also no longer necessarily mirror the CET_U MSR format. > > > Instead the kernel would expose a kernel specific format that has > > > the > > > needed bits of shadow stack support. And a separate one later for > > > IBT. > > > > > > So the question is what does shadow stack need to support for > > > ptrace > > > besides SSP? Is it only SSP? The other features are SHSTK_EN and > > > WRSS_EN. It might actually be nice to keep how these bits get > > > flipped > > > more controlled (remove them from ptrace). It looks like CRIU > > > didn't > > > need them. > > > > > > CRIU reads CET_U with ptrace(PTRACE_GETREGSET, NT_X86_CET). It's done > > before the injection of the parasite. The value of SHSTK_EN is used > > then to > > detect if shadow stack is enabled and to setup victim's shadow stack > > for > > sigreturn. > > Hmm, can it read /proc/pid/status? It has some lines like this: > x86_Thread_features: shstk wrss > x86_Thread_features_locked: shstk wrss It could, but that would be much more intrusive than GETREGSET because currently /proc parsing and parasite injection don't really interact. If anything, arch_prctl(ARCH_CET_GET) via ptrace would be much nicer than /proc.
diff --git a/arch/x86/include/asm/fpu/regset.h b/arch/x86/include/asm/fpu/regset.h index 4f928d6a367b..8622184d87f5 100644 --- a/arch/x86/include/asm/fpu/regset.h +++ b/arch/x86/include/asm/fpu/regset.h @@ -7,11 +7,12 @@ #include <linux/regset.h> -extern user_regset_active_fn regset_fpregs_active, regset_xregset_fpregs_active; +extern user_regset_active_fn regset_fpregs_active, regset_xregset_fpregs_active, + cetregs_active; extern user_regset_get2_fn fpregs_get, xfpregs_get, fpregs_soft_get, - xstateregs_get; + xstateregs_get, cetregs_get; extern user_regset_set_fn fpregs_set, xfpregs_set, fpregs_soft_set, - xstateregs_set; + xstateregs_set, cetregs_set; /* * xstateregs_active == regset_fpregs_active. Please refer to the comment diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h index 10ac52705892..674c508798ee 100644 --- a/arch/x86/include/asm/msr-index.h +++ b/arch/x86/include/asm/msr-index.h @@ -437,6 +437,11 @@ #define CET_RESERVED (BIT_ULL(6) | BIT_ULL(7) | BIT_ULL(8) | BIT_ULL(9)) #define CET_SUPPRESS BIT_ULL(10) #define CET_WAIT_ENDBR BIT_ULL(11) +#define CET_EG_LEG_BITMAP_BASE_MASK GENMASK_ULL(63, 13) + +#define CET_U_IBT_MASK (CET_ENDBR_EN | CET_LEG_IW_EN | CET_NO_TRACK_EN | \ + CET_NO_TRACK_EN | CET_SUPPRESS_DISABLE | CET_SUPPRESS | \ + CET_WAIT_ENDBR | CET_EG_LEG_BITMAP_BASE_MASK) #define MSR_IA32_PL0_SSP 0x000006a4 /* ring-0 shadow stack pointer */ #define MSR_IA32_PL1_SSP 0x000006a5 /* ring-1 shadow stack pointer */ diff --git a/arch/x86/kernel/fpu/regset.c b/arch/x86/kernel/fpu/regset.c index 75ffaef8c299..21225b994b2d 100644 --- a/arch/x86/kernel/fpu/regset.c +++ b/arch/x86/kernel/fpu/regset.c @@ -8,6 +8,7 @@ #include <asm/fpu/api.h> #include <asm/fpu/signal.h> #include <asm/fpu/regset.h> +#include <asm/prctl.h> #include "context.h" #include "internal.h" @@ -174,6 +175,95 @@ int xstateregs_set(struct task_struct *target, const struct user_regset *regset, return ret; } +int cetregs_active(struct task_struct *target, const struct user_regset *regset) +{ +#ifdef CONFIG_X86_USER_SHADOW_STACK + if (target->thread.features & CET_SHSTK) + return regset->n; +#endif + return 0; +} + +int cetregs_get(struct task_struct *target, const struct user_regset *regset, + struct membuf to) +{ + struct fpu *fpu = &target->thread.fpu; + struct cet_user_state *cetregs; + + if (!boot_cpu_has(X86_FEATURE_USER_SHSTK)) + return -ENODEV; + + sync_fpstate(fpu); + cetregs = get_xsave_addr(&fpu->fpstate->regs.xsave, XFEATURE_CET_USER); + if (!cetregs) { + /* + * The registers are the in the init state. The init values for + * these regs are zero, so just zero the output buffer. + */ + membuf_zero(&to, sizeof(struct cet_user_state)); + return 0; + } + + return membuf_write(&to, cetregs, sizeof(struct cet_user_state)); +} + +int cetregs_set(struct task_struct *target, const struct user_regset *regset, + unsigned int pos, unsigned int count, + const void *kbuf, const void __user *ubuf) +{ + struct fpu *fpu = &target->thread.fpu; + struct xregs_state *xsave = &fpu->fpstate->regs.xsave; + struct cet_user_state *cetregs, tmp; + int r; + + if (!boot_cpu_has(X86_FEATURE_USER_SHSTK) || + !cetregs_active(target, regset)) + return -ENODEV; + + r = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &tmp, 0, -1); + if (r) + return r; + + /* + * Some kernel instructions (IRET, etc) can cause exceptions in the case + * of disallowed CET register values. Just prevent invalid values. + */ + if ((tmp.user_ssp >= TASK_SIZE_MAX) || !IS_ALIGNED(tmp.user_ssp, 8)) + return -EINVAL; + + /* + * Don't allow any IBT bits to be set because it is not supported by + * the kernel yet. Also don't allow reserved bits. + */ + if ((tmp.user_cet & CET_RESERVED) || (tmp.user_cet & CET_U_IBT_MASK)) + return -EINVAL; + + fpu_force_restore(fpu); + + /* + * Don't want to init the xfeature until the kernel will definetely + * overwrite it, otherwise if it inits and then fails out, it would + * end up initing it to random data. + */ + if (!xfeature_saved(xsave, XFEATURE_CET_USER) && + WARN_ON(init_xfeature(xsave, XFEATURE_CET_USER))) + return -ENODEV; + + cetregs = get_xsave_addr(xsave, XFEATURE_CET_USER); + if (WARN_ON(!cetregs)) { + /* + * This shouldn't ever be NULL because it was successfully + * inited above if needed. The only scenario would be if an + * xfeature was somehow saved in a buffer, but not enabled in + * xsave. + */ + return -ENODEV; + } + + memmove(cetregs, &tmp, sizeof(tmp)); + return 0; +} + #if defined CONFIG_X86_32 || defined CONFIG_IA32_EMULATION /* diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c index eed8a65d335d..f9e6635b69ce 100644 --- a/arch/x86/kernel/ptrace.c +++ b/arch/x86/kernel/ptrace.c @@ -51,6 +51,7 @@ enum x86_regset_32 { REGSET_XSTATE32, REGSET_TLS32, REGSET_IOPERM32, + REGSET_CET32, }; enum x86_regset_64 { @@ -58,6 +59,7 @@ enum x86_regset_64 { REGSET_FP64, REGSET_IOPERM64, REGSET_XSTATE64, + REGSET_CET64, }; #define REGSET_GENERAL \ @@ -1267,6 +1269,15 @@ static struct user_regset x86_64_regsets[] __ro_after_init = { .active = ioperm_active, .regset_get = ioperm_get }, + [REGSET_CET64] = { + .core_note_type = NT_X86_CET, + .n = sizeof(struct cet_user_state) / sizeof(u64), + .size = sizeof(u64), + .align = sizeof(u64), + .active = cetregs_active, + .regset_get = cetregs_get, + .set = cetregs_set + }, }; static const struct user_regset_view user_x86_64_view = { @@ -1336,6 +1347,15 @@ static struct user_regset x86_32_regsets[] __ro_after_init = { .active = ioperm_active, .regset_get = ioperm_get }, + [REGSET_CET32] = { + .core_note_type = NT_X86_CET, + .n = sizeof(struct cet_user_state) / sizeof(u64), + .size = sizeof(u64), + .align = sizeof(u64), + .active = cetregs_active, + .regset_get = cetregs_get, + .set = cetregs_set + }, }; static const struct user_regset_view user_x86_32_view = { diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h index c7b056af9ef0..11089731e2e9 100644 --- a/include/uapi/linux/elf.h +++ b/include/uapi/linux/elf.h @@ -406,6 +406,7 @@ typedef struct elf64_shdr { #define NT_386_TLS 0x200 /* i386 TLS slots (struct user_desc) */ #define NT_386_IOPERM 0x201 /* x86 io permission bitmap (1=deny) */ #define NT_X86_XSTATE 0x202 /* x86 extended state using xsave */ +#define NT_X86_CET 0x203 /* x86 CET state */ #define NT_S390_HIGH_GPRS 0x300 /* s390 upper register halves */ #define NT_S390_TIMER 0x301 /* s390 timer register */ #define NT_S390_TODCMP 0x302 /* s390 TOD clock comparator register */