public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Luca Boccassi <bluca@debian.org>
Cc: elfutils-devel@sourceware.org, Tom Stellard <tstellar@redhat.com>
Subject: Re: [PATCH v2] libebl: recognize FDO Packaging Metadata ELF note
Date: Sat, 26 Mar 2022 17:33:26 +0100	[thread overview]
Message-ID: <Yj9AVspfBtHQeCvu@wildebeest.org> (raw)
In-Reply-To: <ae29ed812ee150bf96d523d7d445188f42d7f09b.camel@debian.org>

Hi Luca,

On Fri, Mar 25, 2022 at 02:55:14PM +0000, Luca Boccassi wrote:
> On Fri, 2022-03-25 at 15:47 +0100, Mark Wielaard wrote:
> > > We have completely overlooked that, the note is created by a linker
> > > script, which is generated at build time by this:
> > > 
> > > https://github.com/systemd/package-notes/blob/main/generate-package-notes.sh#L254
> > > 
> > > (well an older version in Fedora, but similar enough)
> > 
> > Yeah, that is definitely wrong. ELF is very careful about endianess. I
> > have a patch that detects it and works around it. But it is somewhat
> > ugly and has to work very low-level. So I am not sure I really want it.
> > Maybe I just apply it as a temporary workaround just for Fedora. But if
> > other distros have used such a script to generate package notes they
> > are also broken.
> > 
> > diff --git a/libelf/gelf_getnote.c b/libelf/gelf_getnote.c
> > [...]
> > @@ -73,6 +74,22 @@ gelf_getnote (Elf_Data *data, size_t offset, GElf_Nhdr *result,
> >  	offset = 0;
> >        else
> >  	{
> > +	  /* Workaround FDO package notes on big-endian systems,
> > +	     getting namesz and descsz wrong. Detect it by getting
> > +	     a bad namesz, descsz and byte swapped n_type for
> > +	     NT_FDO_PACKAGING_METADATA.  */
> > +	  if (unlikely (n->n_type == bswap_32 (NT_FDO_PACKAGING_METADATA)
> > +			&& n->n_namesz > data->d_size
> > +			&& n->n_descsz > data->d_size))
> > +	    {
> > +	      /* n might not be writable, use result and redirect n.  */
> > +	      *result = *n;
> > +	      result->n_type = bswap_32 (n->n_type);
> > +	      result->n_namesz = bswap_32 (n->n_namesz);
> > +	      result->n_descsz = bswap_32 (n->n_descsz);
> > +	      n = result;
> > +	    }
> > +
>
> Thanks, but I don't think it's necessary to apply that just now - this
> is a bug and I'll get a fix in the script first in the next couple
> days, and then I'll chat with the Fedora dev working on this about what
> to do regarding existing binaries.

I did apply it to the Fedora package already:
https://src.fedoraproject.org/rpms/elfutils/blob/rawhide/f/elfutils-0.186-fdo-swap.patch
Without it almost all of the selftests fail. And it seems a lot of
binaries on Fedora have already been compiled with this bogus ELF
notes in it. The trouble with that is that the notes themselves are
bad (the sizes are garbage, so anything trying to parse them will fail
and will be unable to parse any notes in the same segement.

> > Note that Tom (on CC) submitted an IMHO much saner way to generate the
> > package notes using simple assembly which would have gotten all this
> > correct automagically.
> > https://src.fedoraproject.org/fork/tstellar/rpms/package-notes/c/25687ec2d8a4262d5ba5c55d35d68a994b892910
> > 
> > I see you rejected that, but please reconsider. Just hardcoding some
> > byte values really is broken.
> 
> The reality of having to deal with thirty thousand different build
> system, integrated with different tools, and different packaging
> systems, with different build scripts, on different distros, means that
> ease of integration trumps over everything else. There are packages out
> there using build systems that you couldn't even imagine in your worst
> nightmares :-)

I can imagine that, but to be honest I think that is precisely because
you are using a linker script. Best would be to make sure there is
native support in the linker for this, just like linkers have native
support for build-ids. Otherwise linking in a simple assembly
generated note seems a good idea. Linker scripts seem the most
fragile.

But if you insist using linker script please use the proper BYTE,
SHORT, LONG directives to store the ELF note structure values, instead
of a stream of BYTEs, so the linker can take care of the correct value
(endianness) representation for the target arch.

Cheers,

Mark


  reply	other threads:[~2022-03-26 16:33 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-19  0:31 [PATCH] " luca.boccassi
2021-11-21 16:33 ` Mark Wielaard
2021-11-21 19:54   ` Luca Boccassi
2021-11-21 19:43 ` [PATCH v2] " luca.boccassi
2021-11-25 17:02   ` Luca Boccassi
2021-11-30 11:25     ` Mark Wielaard
2021-11-30 12:37       ` Luca Boccassi
2021-11-30 16:23       ` Frank Ch. Eigler
2021-11-30 16:49         ` Florian Weimer
2021-11-30 20:04           ` Mark Wielaard
2021-12-02 15:16           ` Frank Ch. Eigler
2021-12-02 15:44             ` Florian Weimer
2021-12-05 17:36       ` Mark Wielaard
2022-03-24 23:14         ` Mark Wielaard
2022-03-24 23:14           ` [PATCH 1/3] libelf: Sync elf.h from glibc Mark Wielaard
2022-03-24 23:14           ` [PATCH 2/3] libebl: recognize FDO Packaging Metadata ELF note Mark Wielaard
2022-03-24 23:14           ` [PATCH 3/3] elflint: Recognize NT_FDO_PACKAGING_METADATA Mark Wielaard
2022-03-25 11:17           ` [PATCH v2] libebl: recognize FDO Packaging Metadata ELF note Luca Boccassi
2022-03-25 13:39             ` Mark Wielaard
2022-03-25 13:52               ` Luca Boccassi
2022-03-25 14:47                 ` Mark Wielaard
2022-03-25 14:55                   ` Luca Boccassi
2022-03-26 16:33                     ` Mark Wielaard [this message]
2022-03-26 16:57                       ` Luca Boccassi
2022-03-26 18:19                         ` Luca Boccassi
2022-03-28  9:57                           ` Mark Wielaard
2022-03-28 10:41                             ` Luca Boccassi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yj9AVspfBtHQeCvu@wildebeest.org \
    --to=mark@klomp.org \
    --cc=bluca@debian.org \
    --cc=elfutils-devel@sourceware.org \
    --cc=tstellar@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).