Re: [PATCH 1/2] x86/shstk: support via prctl

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.