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. > 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?
