Changes/Package information on ELF objects

Change Proposal Name

Package information on ELF objects

Summary

All binaries (executables and shared libraries) are annotated with an ELF note that identifies the rpm distributing this file.

Owner

• Name: Zbigniew Jędrzejewski-Szmek
• Email: zbyszek@in.waw.pl

Current status

• Targeted release: Fedora 35
• Last updated: 2021-03-01
• FESCo issue: <will be assigned by the Wrangler>
• Tracker bug: <will be assigned by the Wrangler>
• Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

See https://github.com/systemd/systemd/issues/18433 for discussion and implementation proposals.

Programs crash. And when they do, they dump core, and we want to tell the user which package, including the version, caused the failure. ELF note .note.package will be added to specify package nevra. By embedding the this information directly in the binary object, package nevra is immediately available from a core dump.

We already have build-ids: every ELF object has a .note.gnu.build-id note, and given a core file, we can read the build-id and look it up in the rpm database (dnf repoquery --whatprovides debuginfo(build-id) = …) to map it to a package name. Build-ids and unique and compact and very generic and work as expected in general. But they have some downsides:

• build-ids are not very informative for users. Before the build-id is converted back to the appropriate package, it's essentially meaningless.
• build-ids require a working rpm database to map to the package name.

Two important cases:

• minimal containers: the rpm database is not installed in the containers. The information about build-ids needs to be stored externally, so package name information is not available immediately, but only after offline processing. The new note doesn't depend on the rpm db in any way.
• self-built and external packages: unless a lot of care is taken to keep access to the debuginfo packages, this information may be lost. The new note is available even if the repository metadata gets lost. Users can easily provide equivalent information in a format that makes sense in their own environment. It should work even when rpms and dpkgs and other formats are mixed, e.g. during container image creation.

The new note is created and propagated similarly to .gnu.build-id. The difference is that we inject the information about package nevra from the build system.

The overhead is 200–300 bytes per each ELF object. If we do this only for executables, than for the whole distro, 5000 * 300 = 1.25MB. If we do it for shared libraries, then the cost will be maybe 4 times higher. Precise measurements TBD once we know the final implementation and figure out the right repoquery magic.

Benefit to Fedora

A simple and reliable way to gather information about package versions of crashing programs is added. It enhances, instead of replacing, any existing mechanisms. It gives us a nicer story for debugging programs in containers.

Scope

• Proposal owners:
  • create a specification
  • provide a patch for redhat-rpm-config to insert appropriate compilation options
  • extend systemd's coredumpctl to extract and display this information
  • submit pull request to Packaging Guidelines

• Other developers:
  • possibly add support in abrt?

• Release engineering: #Releng issue number

There should be no impact.

• Policies and guidelines:

The new flags should be mentioned in Packaging Guidelines.

• Trademark approval: N/A (not needed for this Change)

N/A

• Alignment with Objectives:

It might be relevant for Minimization. Even though it increases the image size a tiny bit, it makes minimized images work a bit better.

Upgrade/compatibility impact

No impact.

How To Test

$ bash -c 'kill -SEGV $$'
$ coredumpctl
TIME                            PID  UID  GID SIG     COREFILE EXE            SIZE PACKAGE

Mon 2021-03-01 14:37:22 CET  855151 1000 1000 SIGSEGV present  /usr/bin/bash 51.7K bash-5.1.0-2.fc34.x86_64

User Experience

coredumpctl should display information about package versions.

Dependencies

None.

Contingency Plan

• Contingency mechanism: Remove the new compilation flags. Rebuild any packages that were build with the new flags.
• Contingency deadline: Beta freeze.
• Blocks release? No.

Documentation

TBD.