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

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

 



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




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux