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.
