Re: [PATCH 00/35] Shadow stacks for userspace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux