+ 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@xxxxxxxxx> > > > > 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.
