[PATCH 1/2] aarch64: Lock GCS with glibc.cpu.aarch64_gcs_lock tunable

[Yury Khrustalev]

On Fri, Dec 19, 2025 at 09:20:43AM -0300, Adhemerval Zanella Netto wrote:
> 
> On 19/12/25 06:57, Yury Khrustalev wrote:
> > On Thu, Dec 18, 2025 at 01:57:39PM -0300, Adhemerval Zanella Netto wrote:
> >>
> >> On 18/12/25 12:57, Yury Khrustalev wrote:
> >>> * Adhemerval
> >>>
> >>> On Wed, Dec 17, 2025 at 05:17:36PM -0300, Adhemerval Zanella Netto wrote:
> >>>>
> >>>> On 12/12/25 12:46, Yury Khrustalev wrote:
> >>>>> This tunable controls locking status of Guarded Control Stack
> >>>>> (GCS) for the process when GCS is enabled:
> >>>>>
> >>>>> ...
> >>>>>
> >>>> I am not sure if this hardening is better server with a tunable
> >>>> than through a GNU property on the ET_EXEC itself.
> >>>
> >>> I don't think I follow you. It is expected that the same binary might
> >>> be run with and without locking without recompiling this binary, for
> >>> example a binary package for Linux distro is built with GCS support,
> >>> and when someone installs this package they can choose whether to
> >>> enforce GCS locking or not.
> >>
> >> Because I am not sure tunables is right way to add and enforce security
> >> hardening:
> > 
> > This new tunable allows to turn off locking explicitly. By default GCS
> > locking is enabled (provided that GCS is activated, of course). So GCS
> > is opt-in and GCS-lock is opt-out.
> > 
> > Binary providers (e.g. distros) can choose to patch Glibc to tweak the
> > default tunable values to enforce certain behaviour unless it is
> > modified through environment in some other way. For now default tunable
> > values are chosen to make GCS opt-in. Later we can change it to opt-out.
> 
> My main issue is the tunable requirement, not the GCS locking by default.

We can just lock it unconditionally.

> This kernel bug is *really* annoying, and although the tunable gives users a 
> way to overcome it, the question is if we really have a widely GCS deployment
> that would really require such workaround.

The aarch64_gcs_lock tunable is NOT a workaround for that bug. Similar
to the aarch64_gcs tunable, it allows for flexible deployment of the new
security feature to avoid any blockers. It would be a shame if shadow
stack would have to be disabled for the whole system simply because one
app can't work with it until it's fixed.

> We added the glibc.rtld.execstack mainly because we had a subtle issue where
> an exported glibc interface lowered hardening guarantee under the hood (and
> without being clear about it in documentation).  And a lot of programs were
> closed-source which required users to explicit change the *binary* by 
> removing the PT_GNU_STACK.
> 
> I am not sure we are in the same position regarding GCS deployment.  There
> are no processors currently available in the consumer or server market with
> GCS support, no commercial or community distro with GCS enabled, and I would
> expect that any deployment would require the GCS locking state fix.

This seems a bit off topic. We just want Glibc to be ready and tested by the
time wide deployment starts.