[PATCH] Link startup files without package-metadata

[Sam James]

Dimitri John Ledkov <dimitri.ledkov@chainguard.dev> writes:

> Many distributions are enabling --package-metadata [1] linker
> flags. This is often done with spec files, config files, toolchain
> wrappers, in ways that might not be obvious that --package-metadata is
> enabled.

We had a similar problem in the past for build IDs which I've been
meaning to send a patch for as well.

>
> When --package-metadata is set for the build, a section is added to
> libc.so.6 but also all glibc produced binaries and the start-up
> files. The startup files are linked to many other binaries. This leads
> to a couple of unexpected side effects.
>
> Binaries built as part of glibc built, often have duplicate and
> triplicate sections for package version metadata. It is redundant, but
> is mostly harmless.
>
> Binaries compiled and linked with these glibc startup files which also
> have package-metadata notes during their builds, end up having
> duplicate notes: one for a given application, and one for glibc.
>
> ```
> Displaying notes found in: .note.package
>   Owner                Data size 	Description
>   FDO                  0x00000058	FDO_PACKAGING_METADATA
>     Packaging Metadata: {"type":"apk","os":"wolfi","name":"glibc","version":"2.42-r7","architecture":"x86_64"}
>   FDO                  0x00000064	FDO_PACKAGING_METADATA
>     Packaging Metadata: {"type":"apk","os":"wolfi","name":"ncurses","version":"6.6_p20251230-r1","architecture":"x86_64"}
> ```
>
> This is accurate, but can generate many missleading false positive CVE
> detections. Many vulnerability scanners can parse this information,
> and upon new glibc CVEs flag up vulnerabilities in such
> binaries. However, most glibc vulnerabilities are not in the startup
> files - but in the dynamically linked libc.so/libm.so.
>
> There are a couple of ways to reduce these false positive detections:
> either package-metadata should be bespoke for the startup files
> (glibc-crt instead of glibc), or complely omitted (without
> package-metadata). As on the balance of probabilities most glibc CVEs
> are not in the startup files.
>
> With this patch the package-notes are suppressed for the startup
> files, ensuring glibc package-note does not bleed into all linked
> binaries ever.
>
> No configure time checks added for this, as --package-metadata option
> is supported by binutils (>= 2.39), mold (>= 1.3.0), lld (>=
> 15.0.0). And build already requires binutils 2.39.
>
> [1] https://uapi-group.org/specifications/specs/package_metadata_for_executable_files/
> ---
>  csu/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/csu/Makefile b/csu/Makefile
> index 2afb70b687..cac2dc6cfc 100644
> --- a/csu/Makefile
> +++ b/csu/Makefile
> @@ -174,7 +174,7 @@ include ../Rules
>  subdir_lib: $(extra-objs:%=$(objpfx)%)
>  
>  define link-relocatable
> -$(CC) -nostdlib -nostartfiles -r -o $@ $^
> +$(CC) -Wl,--package-metadata= -nostdlib -nostartfiles -r -o $@ $^

LGTM.

Reviewed-by: Sam James <sam@gentoo.org>

>  endef
>  
>  ifndef start-installed-name-rule
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 418 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20260219/3040dfb1/attachment.sig>