Bug#1125774: GCS warnings (was: Re: Bug#1125774: ndpi: FTBFS on arm64: missing symbol)

[Emanuele Rocca]

On 2026-01-19 01:25, Adrian Bunk wrote:
> On Sun, Jan 18, 2026 at 06:53:36PM +0100, Andreas Metzler wrote:
> > 1) GCS is an optional feature. dpkg-buildflags now enables it by default
> > on arm64 but gcc only warns when this does not succeed.
> > 2) libgcrypt is not yet supporting it (I suspect because there is asm in play)
> > 3) ndpi FTBFS because of AC_LANG_WERROR.
> > 
> > I cannot see how this can be more than a minor or wishlist bug in
> > libgcrypt and a serious bug in ndpi as long as GCS is an optional
> > feature.[1] So 1125774 should be against ndpi.
> > 
> > I do not intend to play reassigning ping-pong. - Please re-assign back
> > if you consider my rationale convincing.
> 
> My thinking here is about trying to understand the root cause first,
> and then continue from that. With all initial information and discussion
> in one bug.
> 
> ndpi only failed much later due to a missing symbol, this might just be 
> the tip of a much larger iceberg of packages that silently get compiled 
> differently on arm64 the next time they get rebuilt.
> 
> If possible this should be fixed in libgcrypt20, and then there is 
> nothing to do in ndpi.
> 
> If this is for some reason not (easily) possible, then a bug setup as 
> you suggest makes sense.

Adding GCS support to libgcrypt20 requires assembly work. It was done
for PAC and BTI, not yet for GCS:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=55e2e23401c64541e88aad84b5f9e8b1e4ab6acb

The ndpi issue (#1125774) on the other hand can be fixed by disabling
the GCS warning.

Now to recap the situation. There are no immediate practical issues for
our users if some shared libraries or programs don't have GCS yet. The
feature is optional and turned off by default. Users can opt-in by using
a glibc tunable:
https://wiki.debian.org/ToolChain/GCS#GLIBC_tunable

Further down the road, once we increase our coverage of ELF files supporting
GCS in the archive, we may want to analyze specific programs and see if they
(and the shared libraries they use) have GCS support turned on. If everything
works well during testing we can consider enabling the tunable in the systemd
unit shipped by Debian, so that users get the security benefits without manual
fiddling.

For people who choose to manually turn on GCS by passing the GLIBC tunable, the
runtime behavior depends on the value specified:

 0) Disabled: GCS will not be enabled for the process (default)
 1) Enforced: check binary markings and fail if any of the binaries are not marked
 2) Optional: check markings but keep GCS off if there is an unmarked binary
 3) Optional: enable GCS, regardless of binary markings 

The default (0) and (2) present no issues.

Specifying (1) or (3) can cause runtime failures if some of the ELF files (say
libgcrypt) don't have GCS turned on.

This is the reason behind the linker warning we have seen so often, to
inform users about shared libraries without GCS support and the fact
that they may be facing runtime errors. The warning provides valuable
information to someone actively enabling GCS and trying to figure out
what the missing pieces are. Libraries may be missing the marking
because they have not been built with a sufficiently up-to-date
toolchain yet, because they don't honor the build flags we specify by
default in dpkg-buildflags, or because they use assembly code that needs
to be manually updated (like in the case of libgcrypt).
https://wiki.debian.org/ToolChain/GCS#Dealing_with_assembly_code

One could argue that the warning can also be useful for us as a distribution to
see which packages need work. However, I am analyzing the archive on a daily
basis, with a full list of all ELF files in Debian and whether they have
PAC/BTI/GCS enabled or not: https://people.debian.org/~ema/sid-arm64-elffiles/
I think this is a more comprehensive view, and easier to work with than
grepping log files for warnings.

Now for the problems. At this stage in Debian we have seen the following
issues:

1) FTBFS bugs on packages considering warnings as errors. There have been quite
   a few of these, for example avogadro https://bugs.debian.org/1110448

2) Autopkgtest failures. Given that warnings are sent to standard error, any
   package building programs during their tests may start failing. See lib25519:
   https://bugs.debian.org/1123048

3) Autoconf feature misdetection. Some programs specify AC_LANG_WERROR in
   configure.ac, meaning that any build warnings should be considered errors.
   This can result in features not being detected even though they are absolutely
   there and would work fine. We first realized that this is an issue only very
   recently (this weekend) with ndpi https://bugs.debian.org/1125774

The failure mode for (1) and (2) is obvious: FTBFS, autopkgtest failure.
However, as Adrian pointed out, (3) is more subtle. We caught the ndpi issue
because of a symbol difference resulting in a FTBFS, but in other cases we may
get programs built with a different subset of features on arm64 according to
which shared libraries they depend on.

A possible solution is disabling the warning in debian/rules. However
this is ad-hoc, does not scale, and still leaves us with the
AC_LANG_WERROR uncertainties. I have discussed the warning with binutils
upstream (Andres and Matthieu, in CC) some time ago, and there is now a
patch from Matthieu under consideration:
https://inbox.sourceware.org/binutils/20260109095826.1940730-1-matthieu.longo@arm.com/

Once that gets merged, the warning will only be reported to users who
really are trying to enable GCS in their programs by building with '-z
gcs=always'. For the specific case of ndpi we could either wait for that
to happen and then biNMU, or explicitly disable the warning in
debian/rules. I'd like to hear what you think.

My proposal is that meanwhile we go through packages using
AC_LANG_WERROR and see if anything needs fixing. I suppose that grepping
for GCS in config.log should be sufficient to identify problematic ones,
but if you have other ideas please let me know.

  ema