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

[Yury Khrustalev]

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.

> > ...
> > 
> > Why? tunables are used in this case specifically to maximise
> > flexibility of deployment.
> 
> I was hoping that we could also move the glibc.cpu.aarch64_gcs to be
> GNU attributes to avoid the same aforementioned issues above.

If we back a new security feature in the binary, users will have to use
whatever choice is made by the builder of the binary package. The way I
see it, this is contrary to the approach behind deployment of these
features.

> ...

In general, I think that Glibc should provide a tool to choose runtime
configuration, it should up to the distros to choose which model they
prefer to use. On the level of Glibc we should not be enforcing
anything.

Thanks,
Yury