[v3,35/37] x86/cet: Add PTRACE interface for CET
Commit Message
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.
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. Enabling shadow stack involves more than just flipping the
bit. The kernel is made aware that it has to do extra things when cloning
or handling signals. That logic is triggered off of separate feature
enablement state kept in the task struct. So the flipping on HW shadow
stack enforcement without notifying the kernel to change its behavior
would severely limit what an application could do without crashing. Since
there is likely no use for this, only allow the CET registers to be set
if shadow stack is already enabled via the arch_prctl()s. This will let
apps like GDB toggle shadow stack enforcement for apps that already have
shadow stack enabled, and minimize scenarios the kernel has to worry
about.
Tested-by: Pengfei Xu <pengfei.xu@intel.com>
Tested-by: John Allen <john.allen@amd.com>
Co-developed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
---
v3:
- Drop dependence on thread.shstk.size, and use thread.features bits
- Drop 32 bit support
v2:
- Check alignment on ssp.
- Block IBT bits.
- Handle init states instead of returning error.
- Add verbose commit log justifying the design.
Yu-Cheng v12:
- Return -ENODEV when CET registers are in INIT state.
- Check reserved/non-support bits from user input.
arch/x86/include/asm/fpu/regset.h | 7 +--
arch/x86/include/asm/msr-index.h | 5 ++
arch/x86/kernel/fpu/regset.c | 90 +++++++++++++++++++++++++++++++
arch/x86/kernel/ptrace.c | 20 +++++++
include/uapi/linux/elf.h | 1 +
5 files changed, 120 insertions(+), 3 deletions(-)
Comments
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.
@@ -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
@@ -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 */
@@ -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
/*
@@ -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 = {
@@ -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 */