On Tue, Jun 18, 2019 at 06:25:51PM +0200, Florian Weimer wrote: > * Dave Martin: > > > On Tue, Jun 18, 2019 at 09:00:35AM -0700, Yu-cheng Yu wrote: > >> On Tue, 2019-06-18 at 18:05 +0200, Florian Weimer wrote: > >> > * Yu-cheng Yu: > >> > > >> > > > I assumed that it would also parse the main executable and make > >> > > > adjustments based on that. > >> > > > >> > > Yes, Linux also looks at the main executable's header, but not its > >> > > NT_GNU_PROPERTY_TYPE_0 if there is a loader. > >> > > > >> > > > > >> > > > ld.so can certainly provide whatever the kernel needs. We need to tweak > >> > > > the existing loader anyway. > >> > > > > >> > > > No valid statically-linked binaries exist today, so this is not a > >> > > > consideration at this point. > >> > > > >> > > So from kernel, we look at only PT_GNU_PROPERTY? > >> > > >> > If you don't parse notes/segments in the executable for CET, then yes. > >> > We can put PT_GNU_PROPERTY into the loader. > >> > >> Thanks! > > > > Would this require the kernel and ld.so to be updated in a particular > > order to avoid breakage? I don't know enough about RHEL to know how > > controversial that might be. > > There is no official ld.so that will work with the current userspace > interface (in this patch submission). Upstream glibc needs to be > updated anyway, so yet another change isn't much of an issue. This is > not a problem; we knew that something like this might happen. > > Sure, people need a new binutils with backports for PT_GNU_PROPERTY, but > given that only very few people will build CET binaries with older > binutils, I think that's not a real issue either. OK, just wanted to check we weren't missing any requirement for x86. This approach should satisfy the requirement for arm64 nicely. Cheers ---Dave
