+ 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:

quoted

From: Yu-cheng Yu <redacted>

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.

quoted

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.