On Wed, Jun 1, 2022 at 10:27 AM Edgecombe, Rick P <rick.p.edgecombe@xxxxxxxxx> wrote: > > 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. The current glibc cet branch: https://gitlab.com/x86-glibc/glibc/-/commits/users/hjl/cet/master locks only available CET features. Since only SHSTK is available, I saw arch_prctl(0x3003 /* ARCH_??? */, 0x2) = 0 CET features are always enabled early in ld.so to allow function calls in the CET enabled ld.so. ld.so always locks CET features even if they are disabled when the program or a dependency library isn't CET enabled. > > 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). We should have a complete list of use cases and design a way to support them. -- H.J.
