Thread (148 messages) 148 messages, 17 authors, 2022-06-09

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

From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Date: 2022-05-31 16:25:24
Also in: linux-arch, linux-doc, linux-mm, lkml

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help