[PATCH] Link startup files without package-metadata

[Dimitri Ledkov]

On Mon, Feb 23, 2026 at 2:12 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Florian Weimer:
>
> > * Dimitri Ledkov:
> >
> >> I attempted to use --remove-section=.note.package on the startup
> >> files; which breaks them and certain hardening no longer works.
> >
> > Was this with strip or objcopy?  This sounds like a binutils bug.  It
> > should remove the section only leave the rest in place (including any
> > hardening notes).
> >
> >> Note current situation is leading to a lot of false positive CVEs, and
> >> is currently leading to many distributions to turn off
> >> package-metadata for the whole glibc build. As finding out where to
> >> toggle this off is not very obvious. For example see
> >> https://launchpad.net/ubuntu/+source/glibc/2.42-2ubuntu1 and
> >> https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2109333
> >
> > The problem is the reloctable link.  Adding package notes with a
> > reloctable link could be useful in some cases, so I can somewhat
> > understand that --package-notes= is not ignored when -r is present
> > on the ld command line.
> >
> > What I'd like to see eventually is that we can track header usage (for
> > both C and C++), statically linked bits, ABI usage during dynamic
> > linking etc. all separately, using some form of notes.  Currently, this
> > information is available from the build system, but it would be nice to
> > have it closer to the binaries produced, perhaps as part of debugging
> > information.
> >
> >> I think fedora also hit similar issues and turned off package-metadata
> >> for all of glibc based on comments on
> >> https://github.com/systemd/package-notes/issues/48 I believe Suse and
> >> Amazon Linux are similarly affected.
> >
> > We disabled package note generation for reloctable links instead, using
> > the GCC specs file we already use.  I don't know if the glibc build
> > system has a way to specify LDFLAGS for final links of executables and
> > shared objects only.  When we tried that approach, we got duplicate
> > notes due to intermediate relocatable links in the build system.  That's
> > why we decided to address the reloctable link problem directly instead.
>
> Dimitri, do you expect any further action here from the glibc project?
>

At the moment - no. But I may come back after investing things more.

On my todo list is to investigate/prototype all the things with both
strip and objcopy to see if there are any issues to report to the
binutils project. Also will continue to investigate the status of
rpmspecs and build options in fedora, to see if things are on there
and how. And then likely do a recommendation to update the
https://github.com/systemd/package-notes

Whilst my patch might not be the solution, I still think things could
be more automatic / better in the glibc upstream, which avoids every
distributor manually performing the same build system fix ups. As
ideally I want to make it easy for everyone to universally enable
package notes without needing to juggle how to do it right for glibc
or other complex projects (for example grub bios builds).

Even looking at fedora spec file it seems more complicated than
necessary—three LDFLAGS are passed to the build system, in addition to
spec file based hardening:
https://src.fedoraproject.org/rpms/glibc/blob/rawhide/f/glibc.spec#_1390

I want these things to be safer and more consistent, with better
observability and propagation than is currently achieved by all glibc
distributors.

Regards,

Dimitri.