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

[Adhemerval Zanella Netto]

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.

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.

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.

> 
>>> ...
>>>
>>> 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
>