public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Luca Boccassi <bluca@debian.org>
To: Mark Wielaard <mark@klomp.org>, elfutils-devel@sourceware.org
Subject: Re: [PATCH v2] libebl: recognize FDO Packaging Metadata ELF note
Date: Fri, 25 Mar 2022 13:52:15 +0000	[thread overview]
Message-ID: <723cfa8d317969f3ea48947da2cd9c3051cbb937.camel@debian.org> (raw)
In-Reply-To: <77321d756629343a321f4e011e52d1a1fcdd7302.camel@klomp.org>

[-- Attachment #1: Type: text/plain, Size: 2819 bytes --]

On Fri, 2022-03-25 at 14:39 +0100, Mark Wielaard wrote:
> Hi Luca,
> 
> On Fri, 2022-03-25 at 11:17 +0000, Luca Boccassi wrote:
> > On Fri, 2022-03-25 at 00:14 +0100, Mark Wielaard wrote:
> > > I took the elf.h update separately. Tweaked your patch a little and
> > > added a patch of my own to make elflint recognize the new note
> > > type.
> > > 
> > >   [PATCH 1/3] libelf: Sync elf.h from glibc.
> > >   [PATCH 2/3] libebl: recognize FDO Packaging Metadata ELF note
> > >   [PATCH 3/3] elflint: Recognize NT_FDO_PACKAGING_METADATA
> > 
> > No problem at all, change looks good, thanks for following up.
> 
> Thanks, I pushed these three patches.
> But I noticed an issue on s390x fedora 36.
> This isn't just elfutils though, binutils also has trouble:
> 
> Displaying notes found in: .note.package
>   Owner                Data size        Description
> readelf: /usr/bin/bash: Warning: note with invalid namesz and/or descsz
> found at offset 0x0
> readelf: /usr/bin/bash: Warning:  type: 0x7e1afeca, namesize:
> 0x04000000, descsize: 0x78000000, alignment: 4
> 
> Note how it seems the sizes are swapped. s390x is a big endian
> platform.
> 
> Do you happen to know what/how the notes are created and if that
> process might produce bad little/big encoding issues?

Agh - I knew big endianess was a bad idea! :-)
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)

I'll flag this, thanks for the report

> > I have included the field in the first PoC that uses the spec in
> > Debian, for the systemd packages:
> > 
> > $ readelf --notes /usr/lib/systemd/systemd | grep Packaging
> >     Packaging Metadata:
> > {"type":"deb","os":"debian","name":"systemd","architecture":"amd64","
> > version":"250.4-1","debugInfoUrl":"https://debuginfod.debian.net"}
> 
> Nice, thanks. I'll look into how to pick up the debugInfoUrl and use
> that automagically if possible.
>
> BTW. I notice that Fedora has an osCpe field where Debian has an os
> field. It would imho be good if one or the other got standardized.

Debian has not adopted the CPE spec in its os-release, so there's no
way to 'source' the appropriate value. Also bear in mind the Debian
version is purely a PoC, opt-in and used only in the systemd package,
there's no proposal for distro-wide adoption. I plan to propose that
eventually, but it will not be anytime soon, other distros need to
adopt it first otherwise chances are it will just be rejected outright,
for no particular reason other than "it's a change, we don't like
change".

-- 
Kind regards,
Luca Boccassi

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2022-03-25 13:52 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 [this message]
2022-03-25 14:47                 ` Mark Wielaard
2022-03-25 14:55                   ` Luca Boccassi
2022-03-26 16:33                     ` Mark Wielaard
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=723cfa8d317969f3ea48947da2cd9c3051cbb937.camel@debian.org \
    --to=bluca@debian.org \
    --cc=elfutils-devel@sourceware.org \
    --cc=mark@klomp.org \
    /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).