Re: [PATCH] qemu: make version available in coredump

[Vladimir Sementsov-Ogievskiy]

On 16.02.23 12:44, Daniel P. Berrangé wrote:
> On Wed, Feb 15, 2023 at 05:05:47PM -0500, Stefan Hajnoczi wrote:
> > On Tue, 7 Jun 2022 at 16:33, Vladimir Sementsov-Ogievskiy
> > <vsementsov@yandex-team.ru> wrote:
> > > Add a variable with QEMU_FULL_VERSION definition. Then the content of
> > > the variable is easily searchable:
> > >
> > >     strings /path/to/core | grep QEMU_FULL_VERSION
> > >
> > > 'volatile' keyword is used to avoid removing the variable by compiler as
> > > unused.
> > >
> > > Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
> > > ---
> > >
> > > Hi all!
> > >
> > > Probably, I just don't know the correct way to get version from core
> > > file. If so, please teach me :)
> >
> > I've never hit this issue because bug reports usually include the QEMU
> > distro package version. Keeping the version string in the core file
> > seems reasonable (unless there is already another way to do this).
> >
> > Something I'm curious about: is the coredump guaranteed to contain
> > static const variables? I wondered if they might be located in the
> > .rodata ELF section and excluded from the coredump because they are
> > referenced in the NT_FILE mmap note instead. Maybe volatile prevents
> > this?
>
> In Fedora / RHEL based systems (and some other distros too IIUC) for
> many years, all binaries have included a "build-id" ELF note which
> uniquely identifies the package build.
>
> Note section [ 3] '.note.gnu.build-id' of 36 bytes at offset 0x3c0:
>    Owner          Data size  Type
>    GNU                   20  GNU_BUILD_ID
>      Build ID: e3143405b7f653a0a65b3295df760fdf2c09ba79
>
> This can be used to query what RPM it came from (assuming the RPM
> is still in your repos)
>
>   dnf repoquery --whatprovides debuginfo(build-id) = ...hash...
>
> this makes it into the coredump files and is what current distro
> tooling uses to find the binary (and libraries).
>
> There are some downsides/limitations with this though, so in
> Fedora 36 a new impl was added alongside which provides full
> package info in json
>
> Note section [ 5] '.note.package' of 136 bytes at offset 0x404:
>    Owner          Data size  Type
>    FDO                  120  FDO_PACKAGING_METADATA
>      Packaging Metadata: 
> {"type":"rpm","name":"qemu","version":"7.0.0-13.fc37","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:37"}

Looks very good

> This format is supported by systemd core dump tools
>
>    https://systemd.io/ELF_PACKAGE_METADATA/
>
> I believe it has been proposed (and possibly implemented?) for
> Debian too.
>
> This is a long winded way of asking, do we really need a QEMU specific
> solution here ? Especially one that only tells us a QEMU verison, and
> nothing about the many libraries QEMU links to which affect its
> operational behaviour.


Generic solution is of course better.

Hmm. I'm on Ubuntu 22.04.

readelf -n /usr/bin/qemu-system-x86_64

Displaying notes found in: .note.gnu.property
  Owner                Data size        Description
  GNU                  0x00000020       NT_GNU_PROPERTY_TYPE_0
      Properties: x86 feature: IBT, SHSTK
        x86 ISA needed: x86-64-baseline

Displaying notes found in: .note.gnu.build-id
  Owner                Data size        Description
  GNU                  0x00000014       NT_GNU_BUILD_ID (unique build ID 
bitstring)
    Build ID: 4298cd7c2623c58e1cd71668d9d48508bb7f8d52

Displaying notes found in: .note.ABI-tag
  Owner                Data size        Description
  GNU                  0x00000010       NT_GNU_ABI_TAG (ABI version tag)
    OS: Linux, ABI: 3.2.0


OK. But I can't find this build-id in core file..

readelf -n /tmp/cores/core.qemu-system-x86.20351.vsementsov-win.1676544081 | 
grep -i 'build'  ----  gets nothing

strings /tmp/cores//core.qemu-system-x86.20351.vsementsov-win.1676544081 | grep 
4298cd7c2623c58e   ---- nothing as well

So the case is to find the package not having the binary, only by core file.

Probably right solution is to fix our workflow so that if you have core file 
you always have corresponding binary as well.

Still, having the information exactly inside core file seems good anyway. Maybe there is 
a generic way to force the system put "Packaging Metadata" into core file on 
creation of it?

--
Best regards,
Vladimir