Mike, Thanks for doing this. Glad to hear this is solvable with the current paradigm. On Tue, 2022-05-31 at 14:59 +0300, Mike Rapoport wrote: > * add ability to unlock shadow stack features using ptrace. This is > required because the current glibc (or at least in the version I used > for > tests) locks shadow stack state when it loads a program. This locking > means > that a process will either have shadow stack disabled without an > ability to > enable it or it will have shadow stack enabled with WRSS disabled and > again, there is no way to re-enable WRSS. With that, ptrace looked > like the > most sensible interface to interfere with the shadow stack locking. So whatever glibc you have lock's features even if it doesn't enable shadow stack? Hmm, I've not encountered this. Which glibc is it? WRSS is a feature where you would usually want to lock it as disabled, but WRSS cannot be enabled if shadow stack is not enabled. Locking shadow stack and WRSS off together doesn't have any security benefits in theory. so I'm thinking glibc doesn't need to do this. The kernel could even refuse to lock WRSS without shadow stack being enabled. Could we avoid the extra ptrace functionality then? Rick
