On Thu, Jan 06, 2022 at 06:13:37PM +0000, Catalin Marinas wrote: > On Thu, Jan 06, 2022 at 10:09:35AM -0600, Jeremy Linton wrote: > > This should only change the behavior for for binaries which conform to the > > new ABI containing the BTI note. So outside of the tiny window of things > > built with BTI, but run on !BTI hardware or older kernel+glibc, this > > shouldn't be a problem. (Unless i'm missing something) Put another way, now > > is the time to make a change, before there is a legacy BTI ecosystem we have > > to deal with. > The concern is that the loader may decide in the future to not enable > (or turn off) BTI for some reason (e.g. mixed libraries, old glibc on > BTI hardware). If we force BTI on the main executable, we'd take this > option away. Note also that it's not only glibc here, there are other > loaders. Neither of those examples should be concerns - BTI is per page so you can mix BTI and non-BTI freely in a process (as will happen now for the case where the dynamic loader is built for BTI but the main executable is not, and the dynamic loader should do if there's a mix of BTI and non-BTI libraries). The main case where there might be a change would be the case where there's individual excutables with incorrect BTI annotations which are run under this seccomp MWDE, then the dynamic loader might have support for disabling BTI based on some configuration but wouldn't be able to due to the MWDE. Note also that we're only taking the option of disabiling BTI away in the case where there's something like this seccomp filter disabling permission changes.
Attachment:
signature.asc
Description: PGP signature
