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