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

[Edgecombe, Rick P]

On Tue, 2022-05-31 at 11:00 -0700, H.J. Lu wrote:
> > The glibc logic seems wrong to me also, because shadow stack or IBT
> > could be force-disabled via glibc tunables. I don't see why the elf
> > header bit should exclusively control the feature locking. Or why
> > both
> > should be locked if only one is in the header.
> 
> glibc locks SHSTK and IBT only if they are enabled at run-time.

It's not what I saw in the code. Somehow Mike saw something different
as well.

>  It doesn't
> enable/disable/lock WRSS at the moment.  If WRSS can be enabled
> via arch_prctl at any time, we can't lock it.  If WRSS should be
> locked early,
> how should it be enabled in application?  Also can WRSS be enabled
> from a dlopened object?

I think in the past we discussed having another elf header bit that
behaved differently (OR vs AND).