Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file

[Dave Martin]

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