On 8/3/26 1:14 PM, Edgecombe, Rick P wrote:
On Mon, 2026-08-03 at 12:41 -0500, Bill Roberts wrote:
Map the generic PR_SHADOW_STACK_ENABLE, PR_SHADOW_STACK_DISABLE, and
PR_SHADOW_STACK_LOCK operations onto the underlying x86 internal CET
helper
routines. This allows portable userspace applications to toggle or query
shadow stack states without relying on architecture-specific system calls,
while maintaining backward compatibility with existing arch_prctl() calls.
Can you explain why not to include ARCH_SHSTK_UNLOCK?
https://lore.kernel.org/lkml/[email protected]
From what I can tell, there is no analogous operation in the common
flow, you lock the thread features, and
the features are locked in perpetuity for the thread. If you need fluid
changes to these bits, you just don't lock
it. If in the future the generic interface gets this, then it would make
sense for sure.
ptrace has as special handling for arch_prctl. So to unlock for CRIU (where
unlock came from), it needs to go via arch_prctl. I wonder what the other arch's
will do for this. If we unify the ABI, it seems the generic one that is getting
implemented in this series is incomplete. Unless the API will be split always
between the two syscalls.
When they add unlock to the generic interface, then that will be the
time to rectify that. Just looking
through patches and stuff, I think that side is still in flight, eg
https://lkml.org/lkml/2026/4/3/1651.
It also looks like the model is slightly different, in that there is a
window when all of this should be
handled, and then locked permanently. I know on our side of the house,
locking isn't really being
used yet. But that's criu, right now, the main things I would like to
coalesce is libc's. As MUSL and
others get patches, it would be much simpler to have one interface to do
this in, and right now
unlock is unused (even in the test suite :-p).
Ill spin out a v2 with the comments, but the one thing left to be
addressed, afaik, is the testing patch
do you want that? I'll drop it, but I think that's a bad approach.
