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

On Tue, 2026-08-04 at 13:23 -0500, Bill Roberts wrote:
> 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.

This looks like it is about clearing lock bits after exec. What I am talking
about is "PTRACE_ARCH_PRCTL". It's a special ptrace capability that only can
poke at arch_prtcl and not regular prctl.

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

IIRC CRIU needed to unlock shadow stack during the save. Because it's tricks for
saving the process involved messing with the stack. So it needs to be able to
unlock but *only* via ptrace. Apps cannot be allowed to unlock themselves.
Because, well, obviously..


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

I think I raised this on the other arch's APIs originally. x86 went first, and
then later arm/riscv wanted a unified approach, but didn't solve this ptrace
unlock part. So we didn't join. AFAICT the situation hasn't changed. So I'm
worried it's too soon to unify. Or we might need to do multiple steps of
unifications.

Also looking forward to understanding the security module problem statement
better.

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

Yea, I hear your point. It is good to test more, but #including c files with
pre-processor switches seems too hacky. Is there anything we could do to make it
in one c file? Like not the templated tricks to generate two test binaries? For
example embed the switch between the two APIs in a macros in the single file.
Like say we have SHSTK_ENABLE(). Inside it does either ARCH_PRCTL() or regular.
Then have a global or something that switches between the two behaviors. Pull
out the parts in main() into something that could be run twice?
_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv