Re: [PATCH] libebl: recognize FDO Packaging Metadata ELF note

[Luca Boccassi <luca.boccassi@gmail.com>]

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

On Sun, 2021-11-21 at 17:33 +0100, Mark Wielaard wrote:
> Hi Luca,
> 
> On Fri, Nov 19, 2021 at 12:31:27AM +0000, luca.boccassi--- via
> Elfutils-devel wrote:
> > From: Luca Boccassi <bluca@debian.org>
> > 
> > As defined on: https://systemd.io/COREDUMP_PACKAGE_METADATA/
> > this note will be used starting from Fedora 36. Allow
> > readelf --notes to pretty print it:
> > 
> > Note section [ 3] '.note.package' of 76 bytes at offset 0x2e8:
> >   Owner          Data size  Type
> >   FDO                   57  FDO_PACKAGING_METADATA
> >     Packaging Metadata: {"type":"deb","name":"fsverity-
> > utils","version":"1.3-1"}
> 
> Very nice. Thanks,
> 
> > diff --git a/libebl/eblobjnote.c b/libebl/eblobjnote.c
> > index 36efe275..1f8bcccf 100644
> > --- a/libebl/eblobjnote.c
> > +++ b/libebl/eblobjnote.c
> > @@ -288,6 +288,9 @@ ebl_object_note (Ebl *ebl, uint32_t namesz, const
> > char *name, uint32_t type,
> >        if (descsz == 0 && type == NT_VERSION)
> >         return;
> >  
> > +      if (strcmp ("FDO", name) == 0 && type ==
> > FDO_PACKAGING_METADATA && descsz > 0)
> > +       printf("    Packaging Metadata: %.*s\n", (int) descsz, desc);
> > +
> 
> We might want to check that the desc is '\0' terminated (although I
> see we also don't do that in other cases, like
> NT_GNU_GOLD_VERSION. But it might be good as a robustness check.

No problem, added in v2.

> > diff --git a/libelf/elf.h b/libelf/elf.h
> > index 8e3e618f..633f9f67 100644
> > --- a/libelf/elf.h
> > +++ b/libelf/elf.h
> > @@ -1297,6 +1297,9 @@ typedef struct
> >  /* Program property.  */
> >  #define NT_GNU_PROPERTY_TYPE_0 5
> >  
> > +/* Packaging metadata as defined on
> > https://systemd.io/COREDUMP_PACKAGE_METADATA/ */
> > +#define FDO_PACKAGING_METADATA 0xcafe1a7e
> > +
> >  /* Note section name of program property.   */
> >  #define NOTE_GNU_PROPERTY_SECTION_NAME ".note.gnu.property"
> 
> Would you mind posting the elf.h patch to glibc-alpha@sourceware.org.
> We normally sync elf.h with the glibc one. It will also make sure
> other users of elf.h also get the new constants.

Sure, done:

https://sourceware.org/pipermail/libc-alpha/2021-November/133330.html

> As a followup I wouldn't mind a minimal testcase.
> Especially if it contains a debuginfod url.
> 
> We would have to think how to integrate that with libdw
> dwfl_build_id_find_elf and dwfl_standard_find_debuginfo which use
> debuginfod_find from the debuginfod-client library.
> 
> Since the payload of the FDO_PACKAGING_METADATA note are not simply
> key/values, but encoded in json, so we will need to add or depend on a
> json parser. Any recommendations? It seems a simple enough format to
> just write our own (especially if we can simply skip everything except
> top-level key/value strings to find the debuginfod-url).
> 
> Thanks,
> 
> Mark

Popular C parsers that I know of are json-c and jannson:

https://github.com/json-c/json-c/wiki
https://digip.org/jansson/

json-c seems to be available in slightly more places:

https://repology.org/project/json-c/versions
https://repology.org/project/jansson/versions

Rolling your own full parser can always end up being tricky and a lot
of work, especially for limited usage with no particular requirements.
You need to ensure you've got good fuzzing, etc. If using one of the
above is optional and tied to the debuginfod feature being enabled,
there shouldn't be issues with bootstrapping.
A simple search for the "debugInfoUrl" string, using whatever string is
quoted next as the url would be much simpler of course, if that's all
you need. Up to you of course.

-- 
Kind regards,
Luca Boccassi

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