[PATCH] Link startup files without package-metadata

[Florian Weimer]

* 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?

Thanks,
Florian