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

[Yury Khrustalev]

* 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:
> > 
> >   0 = unlocked: GCS can be disabled via a prctl() call.
> >   1 = locked: GCS is locked and cannot be disable for the process.
> > 
> > By default, GCS will be locked if enabled. If GCS is not enabled
> > at startup, this tunable has no effect.
> > 
> > Issue a prctl() syscall to lock GCS status based on the value
> > of the glibc.cpu.aarch64_gcs_lock tunable for static and also
> > dynamically-linked binaries.
> > 
> > All operation bits are locked including the future ones. The
> > prctl() syscall will accept this and this will ensure that
> > any future operations are locked as well.
> 
> 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.

> I would expect
> this to be modeled PT_GNU_STACK, even though GCS state is fully
> handled in userland by design.
> 
> It has an extra burden enabling this through binutils and extra
> marking;

Yes, this could be quite prohibitive as it would require ensuring
that supporting version of binutils is present.

> but I think once we start to deploy GCS enable system
> flipping the tunable switch might also have unforseen breakage

Why? tunables are used in this case specifically to maximise
flexibility of deployment.

> (as we saw we start to enforce non-executable stacks).
> 
> The tunable options for GCS is already somewhat complex with
> multiple options depending whether the object has or not 
> GNU_PROPERTY_AARCH64_FEATURE_1_GCS.

Hence the 2nd tunable rather than extension of the 1st one. The
1st tunable aarch64_gcs controls whether GCS is used or not. And
the 2nd one applies locking if GCS is enabled.

Thanks,
Yury