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

[Adhemerval Zanella Netto]

On 19/12/25 10:00, Yury Khrustalev wrote:
> 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.

Yes, that is my position.

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

But in this case it is a matter to either not build the binary with GCS
or use glibc.cpu.aarch64_gcs=0 as stopgap measure.

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

My view is although GNU_PROPERTY_AARCH64_FEATURE_1_GCS is a hint that depends
of the underlying system supports; once it is applied by the dynamic loader
a reasonable assumption that the program should *not* be able to disable it.

The non-exec stack being able to be disabled during process execution was a
mistake and a security hazard.  I do not think we should do something similar
with GCS.