[2/2] aarch64: Accept string values for glibc.cpu.aarch64_gcs tunable

  This patch updates the glibc.cpu.aarch64_gcs tunable to accept
human-readable strings in addition to its standard numerical values.

The tunable now accepts the strings 'disabled', 'enforced', 'optional',
and 'override', mapping them to their corresponding 0, 1, 2, and 3 internal
enum states.

To support custom parsing in architecture-specific code, the
'tunable_parse_num' function is moved to the generic dl-tunables-parse.h
as an inline function.

The '__tunable_print_error' function is exposed globally so that invalid
string inputs caught in the newly added 'aarch64_gcs' callback can trigger
standard tunable warnings.

Checked on aarch64-linux-gnu.
---
 elf/dl-tunables.c                             | 29 +++++++++----------
 elf/dl-tunables.h                             |  3 ++
 manual/tunables.texi                          |  8 ++---
 sysdeps/aarch64/dl-tunables.list              |  5 +---
 sysdeps/generic/dl-tunables-parse.h           | 13 +++++++++
 .../unix/sysv/linux/aarch64/cpu-features.c    | 28 +++++++++++++++++-
 6 files changed, 61 insertions(+), 25 deletions(-)
  

Hello Adhemerval,

On Fri, Mar 27, 2026 at 02:44:24PM -0300, Adhemerval Zanella wrote:
> This patch updates the glibc.cpu.aarch64_gcs tunable to accept
> human-readable strings in addition to its standard numerical values.
> 
> The tunable now accepts the strings 'disabled', 'enforced', 'optional',

Nit: 'now' is ambiguous in a commit message.

> and 'override', mapping them to their corresponding 0, 1, 2, and 3 internal
> enum states.
> 
> To support custom parsing in architecture-specific code, the
> 'tunable_parse_num' function is moved to the generic dl-tunables-parse.h
> as an inline function.
> 
> The '__tunable_print_error' function is exposed globally so that invalid
> string inputs caught in the newly added 'aarch64_gcs' callback can trigger
> standard tunable warnings.

I think that this change is mostly cosmetic and I don't think it's worth
doing given the changes it needs and the increased complexity of the code
that parse this tunable value. GCS tunable should take as little code as
possible to parse it by the nature of it.

See more comments below.

> 
> Checked on aarch64-linux-gnu.
> ---
>  elf/dl-tunables.c                             | 29 +++++++++----------
>  elf/dl-tunables.h                             |  3 ++
>  manual/tunables.texi                          |  8 ++---
>  sysdeps/aarch64/dl-tunables.list              |  5 +---
>  sysdeps/generic/dl-tunables-parse.h           | 13 +++++++++
>  .../unix/sysv/linux/aarch64/cpu-features.c    | 28 +++++++++++++++++-
>  6 files changed, 61 insertions(+), 25 deletions(-)

It would be useful to use these human-readable for Glibc tests to see
if they work.

>
> ...
>
> diff --git a/sysdeps/unix/sysv/linux/aarch64/cpu-features.c b/sysdeps/unix/sysv/linux/aarch64/cpu-features.c
> index 1e4f8a86b1..fe634cbded 100644
> --- a/sysdeps/unix/sysv/linux/aarch64/cpu-features.c
> +++ b/sysdeps/unix/sysv/linux/aarch64/cpu-features.c
> @@ -65,6 +65,31 @@ get_midr_from_mcpu (const struct tunable_str_t *mcpu)
>    return UINT64_MAX;
>  }
>  
> +static void
> +TUNABLE_CALLBACK (aarch64_gcs) (tunable_val_t *valp)
> +{
> +  tunable_num_t val;
> +  if (tunable_parse_num_tun (valp, &val))

The manual says that accepted values right now are 0, 1, 2, and 3. I
don't think we should bother parsing input as an integer only to have
to process the obtained value for possible incorrect values.

We should just compare string value of the tunable with "1", "2", etc.

> +    {
> +      if (tunable_val_lt (val, AARCH64_GCS_POLICY_DISABLED, true))
> +	val = AARCH64_GCS_POLICY_DISABLED;
> +      if (tunable_val_gt (val, AARCH64_GCS_POLICY_OVERRIDE, true))
> +	val = AARCH64_GCS_POLICY_OVERRIDE;
> +      GL(dl_aarch64_gcs) = val;
> +    }

If the value provided by the user is less than 0 or more than 3, it's an
error, we should not implicitly convert it to one of the supported
values.

> +  else if (tunable_strcmp_cte (valp, "disabled"))
> +    GL(dl_aarch64_gcs) = AARCH64_GCS_POLICY_DISABLED;
> +  else if (tunable_strcmp_cte (valp, "enforced"))
> +    GL(dl_aarch64_gcs) = AARCH64_GCS_POLICY_ENFORCED;
> +  else if (tunable_strcmp_cte (valp, "optional"))
> +    GL(dl_aarch64_gcs) = AARCH64_GCS_POLICY_OPTIONAL;
> +  else if (tunable_strcmp_cte (valp, "override"))
> +    GL(dl_aarch64_gcs) = AARCH64_GCS_POLICY_OVERRIDE;
> +  else
> +    __tunable_print_error (valp->strval.str, valp->strval.len,
> +			   "glibc.cpu.aarch64_gcs");
> +}
> +
>  static inline void
>  init_cpu_features (struct cpu_features *cpu_features)
>  {
> @@ -136,5 +161,6 @@ init_cpu_features (struct cpu_features *cpu_features)
>  
>    if (GLRO (dl_hwcap) & HWCAP_GCS)
>      /* GCS status may be updated later by binary compatibility checks.  */
> -    GL (dl_aarch64_gcs) = TUNABLE_GET (glibc, cpu, aarch64_gcs, uint64_t, 0);
> +    TUNABLE_GET (glibc, cpu, aarch64_gcs, tunable_val_t *,
> +		 TUNABLE_CALLBACK (aarch64_gcs));

Thanks,
Yury
  

On 30/03/26 06:40, Yury Khrustalev wrote:
> Hello Adhemerval,
> 
> On Fri, Mar 27, 2026 at 02:44:24PM -0300, Adhemerval Zanella wrote:
>> This patch updates the glibc.cpu.aarch64_gcs tunable to accept
>> human-readable strings in addition to its standard numerical values.
>>
>> The tunable now accepts the strings 'disabled', 'enforced', 'optional',
> 
> Nit: 'now' is ambiguous in a commit message.
> 
>> and 'override', mapping them to their corresponding 0, 1, 2, and 3 internal
>> enum states.
>>
>> To support custom parsing in architecture-specific code, the
>> 'tunable_parse_num' function is moved to the generic dl-tunables-parse.h
>> as an inline function.
>>
>> The '__tunable_print_error' function is exposed globally so that invalid
>> string inputs caught in the newly added 'aarch64_gcs' callback can trigger
>> standard tunable warnings.
> 
> I think that this change is mostly cosmetic and I don't think it's worth
> doing given the changes it needs and the increased complexity of the code
> that parse this tunable value. GCS tunable should take as little code as
> possible to parse it by the nature of it.

It is usability improvement, so not really only 'comestic'.  Sure it is not
strictly required, but it makes the usage and script that eventually need
to setup the GLIBC_TUNABLE more readable to what GCS semantic it wants to
use.

> 
> See more comments below.
> 
>>
>> Checked on aarch64-linux-gnu.
>> ---
>>  elf/dl-tunables.c                             | 29 +++++++++----------
>>  elf/dl-tunables.h                             |  3 ++
>>  manual/tunables.texi                          |  8 ++---
>>  sysdeps/aarch64/dl-tunables.list              |  5 +---
>>  sysdeps/generic/dl-tunables-parse.h           | 13 +++++++++
>>  .../unix/sysv/linux/aarch64/cpu-features.c    | 28 +++++++++++++++++-
>>  6 files changed, 61 insertions(+), 25 deletions(-)
> 
> It would be useful to use these human-readable for Glibc tests to see
> if they work.
> 
>>
>> ...
>>
>> diff --git a/sysdeps/unix/sysv/linux/aarch64/cpu-features.c b/sysdeps/unix/sysv/linux/aarch64/cpu-features.c
>> index 1e4f8a86b1..fe634cbded 100644
>> --- a/sysdeps/unix/sysv/linux/aarch64/cpu-features.c
>> +++ b/sysdeps/unix/sysv/linux/aarch64/cpu-features.c
>> @@ -65,6 +65,31 @@ get_midr_from_mcpu (const struct tunable_str_t *mcpu)
>>    return UINT64_MAX;
>>  }
>>  
>> +static void
>> +TUNABLE_CALLBACK (aarch64_gcs) (tunable_val_t *valp)
>> +{
>> +  tunable_num_t val;
>> +  if (tunable_parse_num_tun (valp, &val))
> 
> The manual says that accepted values right now are 0, 1, 2, and 3. I
> don't think we should bother parsing input as an integer only to have
> to process the obtained value for possible incorrect values.
> 
> We should just compare string value of the tunable with "1", "2", etc.

Alright, we can simplify the parsing with a a more straightforward loop.

> 
>> +    {
>> +      if (tunable_val_lt (val, AARCH64_GCS_POLICY_DISABLED, true))
>> +	val = AARCH64_GCS_POLICY_DISABLED;
>> +      if (tunable_val_gt (val, AARCH64_GCS_POLICY_OVERRIDE, true))
>> +	val = AARCH64_GCS_POLICY_OVERRIDE;
>> +      GL(dl_aarch64_gcs) = val;
>> +    }
> 
> If the value provided by the user is less than 0 or more than 3, it's an
> error, we should not implicitly convert it to one of the supported
> values.

Indeed, it is a mistake in my reading of do_tunable_update_val. If the
value is out of range we should use the default one.

> 
>> +  else if (tunable_strcmp_cte (valp, "disabled"))
>> +    GL(dl_aarch64_gcs) = AARCH64_GCS_POLICY_DISABLED;
>> +  else if (tunable_strcmp_cte (valp, "enforced"))
>> +    GL(dl_aarch64_gcs) = AARCH64_GCS_POLICY_ENFORCED;
>> +  else if (tunable_strcmp_cte (valp, "optional"))
>> +    GL(dl_aarch64_gcs) = AARCH64_GCS_POLICY_OPTIONAL;
>> +  else if (tunable_strcmp_cte (valp, "override"))
>> +    GL(dl_aarch64_gcs) = AARCH64_GCS_POLICY_OVERRIDE;
>> +  else
>> +    __tunable_print_error (valp->strval.str, valp->strval.len,
>> +			   "glibc.cpu.aarch64_gcs");
>> +}
>> +
>>  static inline void
>>  init_cpu_features (struct cpu_features *cpu_features)
>>  {
>> @@ -136,5 +161,6 @@ init_cpu_features (struct cpu_features *cpu_features)
>>  
>>    if (GLRO (dl_hwcap) & HWCAP_GCS)
>>      /* GCS status may be updated later by binary compatibility checks.  */
>> -    GL (dl_aarch64_gcs) = TUNABLE_GET (glibc, cpu, aarch64_gcs, uint64_t, 0);
>> +    TUNABLE_GET (glibc, cpu, aarch64_gcs, tunable_val_t *,
>> +		 TUNABLE_CALLBACK (aarch64_gcs));
> 
> Thanks,
> Yury
>
  

On Mon, Mar 30, 2026 at 03:42:17PM -0300, Adhemerval Zanella Netto wrote:
>
> ...
>
> >> The '__tunable_print_error' function is exposed globally so that invalid
> >> string inputs caught in the newly added 'aarch64_gcs' callback can trigger
> >> standard tunable warnings.
> > 
> > I think that this change is mostly cosmetic and I don't think it's worth
> > doing given the changes it needs and the increased complexity of the code
> > that parse this tunable value. GCS tunable should take as little code as
> > possible to parse it by the nature of it.
> 
> It is usability improvement, so not really only 'comestic'.  Sure it is not
> strictly required, but it makes the usage and script that eventually need
> to setup the GLIBC_TUNABLE more readable to what GCS semantic it wants to
> use.

Users would need to use either 1 or 0 which should be straightforward. I
agree that enum values are easier to use but the amount of code that
needs to run to support them seems to high.

> 
> ...
>
> > 
> >> +    {
> >> +      if (tunable_val_lt (val, AARCH64_GCS_POLICY_DISABLED, true))
> >> +	val = AARCH64_GCS_POLICY_DISABLED;
> >> +      if (tunable_val_gt (val, AARCH64_GCS_POLICY_OVERRIDE, true))
> >> +	val = AARCH64_GCS_POLICY_OVERRIDE;
> >> +      GL(dl_aarch64_gcs) = val;
> >> +    }
> > 
> > If the value provided by the user is less than 0 or more than 3, it's an
> > error, we should not implicitly convert it to one of the supported
> > values.
> 
> Indeed, it is a mistake in my reading of do_tunable_update_val. If the
> value is out of range we should use the default one.

The code in 'dl-gcs.c' treats any out of range value as an error, but it
seems like 'TUNABLE_GET' returns default value in this case. I'm not
sure when this change happened, it seems to add inconsistency between
string and integer tunables. I think that silent change of behaviour is
not ideal, it should be an error.

Thanks,
Yury
  

On 31/03/26 06:02, Yury Khrustalev wrote:
> On Mon, Mar 30, 2026 at 03:42:17PM -0300, Adhemerval Zanella Netto wrote:
>>
>> ...
>>
>>>> The '__tunable_print_error' function is exposed globally so that invalid
>>>> string inputs caught in the newly added 'aarch64_gcs' callback can trigger
>>>> standard tunable warnings.
>>>
>>> I think that this change is mostly cosmetic and I don't think it's worth
>>> doing given the changes it needs and the increased complexity of the code
>>> that parse this tunable value. GCS tunable should take as little code as
>>> possible to parse it by the nature of it.
>>
>> It is usability improvement, so not really only 'comestic'.  Sure it is not
>> strictly required, but it makes the usage and script that eventually need
>> to setup the GLIBC_TUNABLE more readable to what GCS semantic it wants to
>> use.
> 
> Users would need to use either 1 or 0 which should be straightforward. I
> agree that enum values are easier to use but the amount of code that
> needs to run to support them seems to high.

And "disabled" and "enforced" is way more clear than '0' or '1', specially
because the tunable also acceptss other values (which makes it not a boolean
switch, as bti).  

Again, it is not clear why you are blocking this change, since it is a 
usability improvement.

> 
>>
>> ...
>>
>>>
>>>> +    {
>>>> +      if (tunable_val_lt (val, AARCH64_GCS_POLICY_DISABLED, true))
>>>> +	val = AARCH64_GCS_POLICY_DISABLED;
>>>> +      if (tunable_val_gt (val, AARCH64_GCS_POLICY_OVERRIDE, true))
>>>> +	val = AARCH64_GCS_POLICY_OVERRIDE;
>>>> +      GL(dl_aarch64_gcs) = val;
>>>> +    }
>>>
>>> If the value provided by the user is less than 0 or more than 3, it's an
>>> error, we should not implicitly convert it to one of the supported
>>> values.
>>
>> Indeed, it is a mistake in my reading of do_tunable_update_val. If the
>> value is out of range we should use the default one.
> 
> The code in 'dl-gcs.c' treats any out of range value as an error, but it
> seems like 'TUNABLE_GET' returns default value in this case. I'm not
> sure when this change happened, it seems to add inconsistency between
> string and integer tunables. I think that silent change of behaviour is
> not ideal, it should be an error.

It was always like that afaik, since the tunable is defind as an integer
and it uses the generic code that sets the default value in case of
out of range inputs.

To proper validate it we will need either to change the generic tunable
parsing by either adding callback or an option to error in case of
out-of-range; or do it like this patch and parse on arch-specific callback.
  

On Tue, Mar 31, 2026 at 08:58:03AM -0300, Adhemerval Zanella Netto wrote:
> 
> On 31/03/26 06:02, Yury Khrustalev wrote:
> > On Mon, Mar 30, 2026 at 03:42:17PM -0300, Adhemerval Zanella Netto wrote:
> >>
> >> ...
> >>
> >>>> The '__tunable_print_error' function is exposed globally so that invalid
> >>>> string inputs caught in the newly added 'aarch64_gcs' callback can trigger
> >>>> standard tunable warnings.
> >>>
> >>> I think that this change is mostly cosmetic and I don't think it's worth
> >>> doing given the changes it needs and the increased complexity of the code
> >>> that parse this tunable value. GCS tunable should take as little code as
> >>> possible to parse it by the nature of it.
> >>
> >> It is usability improvement, so not really only 'comestic'.  Sure it is not
> >> strictly required, but it makes the usage and script that eventually need
> >> to setup the GLIBC_TUNABLE more readable to what GCS semantic it wants to
> >> use.
> > 
> > Users would need to use either 1 or 0 which should be straightforward. I
> > agree that enum values are easier to use but the amount of code that
> > needs to run to support them seems to high.
> 
> And "disabled" and "enforced" is way more clear than '0' or '1', specially
> because the tunable also acceptss other values (which makes it not a boolean
> switch, as bti).  
> 
> Again, it is not clear why you are blocking this change, since it is a 
> usability improvement.

Like I've mentioned earlier, I believe that the usability benefit that we may
have from this patch does not outweigh the extent of changes in the generic
code and the code that parses this particular tunable. I'd prefer to keep it
simple unless there is a compelling reason to increase complexity.

>
> ...
>
> >>>
> >>> If the value provided by the user is less than 0 or more than 3, it's an
> >>> error, we should not implicitly convert it to one of the supported
> >>> values.
> >>
> >> Indeed, it is a mistake in my reading of do_tunable_update_val. If the
> >> value is out of range we should use the default one.
> > 
> > The code in 'dl-gcs.c' treats any out of range value as an error, but it
> > seems like 'TUNABLE_GET' returns default value in this case. I'm not
> > sure when this change happened, it seems to add inconsistency between
> > string and integer tunables. I think that silent change of behaviour is
> > not ideal, it should be an error.
> 
> It was always like that afaik, since the tunable is defind as an integer
> and it uses the generic code that sets the default value in case of
> out of range inputs.
> 
> To proper validate it we will need either to change the generic tunable
> parsing by either adding callback or an option to error in case of
> out-of-range; or do it like this patch and parse on arch-specific callback.

OK, thanks for clarification.
  

On 31/03/26 09:48, Yury Khrustalev wrote:
> On Tue, Mar 31, 2026 at 08:58:03AM -0300, Adhemerval Zanella Netto wrote:
>>
>> On 31/03/26 06:02, Yury Khrustalev wrote:
>>> On Mon, Mar 30, 2026 at 03:42:17PM -0300, Adhemerval Zanella Netto wrote:
>>>>
>>>> ...
>>>>
>>>>>> The '__tunable_print_error' function is exposed globally so that invalid
>>>>>> string inputs caught in the newly added 'aarch64_gcs' callback can trigger
>>>>>> standard tunable warnings.
>>>>>
>>>>> I think that this change is mostly cosmetic and I don't think it's worth
>>>>> doing given the changes it needs and the increased complexity of the code
>>>>> that parse this tunable value. GCS tunable should take as little code as
>>>>> possible to parse it by the nature of it.
>>>>
>>>> It is usability improvement, so not really only 'comestic'.  Sure it is not
>>>> strictly required, but it makes the usage and script that eventually need
>>>> to setup the GLIBC_TUNABLE more readable to what GCS semantic it wants to
>>>> use.
>>>
>>> Users would need to use either 1 or 0 which should be straightforward. I
>>> agree that enum values are easier to use but the amount of code that
>>> needs to run to support them seems to high.
>>
>> And "disabled" and "enforced" is way more clear than '0' or '1', specially
>> because the tunable also acceptss other values (which makes it not a boolean
>> switch, as bti).  
>>
>> Again, it is not clear why you are blocking this change, since it is a 
>> usability improvement.
> 
> Like I've mentioned earlier, I believe that the usability benefit that we may
> have from this patch does not outweigh the extent of changes in the generic
> code and the code that parses this particular tunable. I'd prefer to keep it
> simple unless there is a compelling reason to increase complexity.

But the complexity is just to add a list of possible value and string comparison,
which is done on multiple tunable checks.  

> 
>>
>> ...
>>
>>>>>
>>>>> If the value provided by the user is less than 0 or more than 3, it's an
>>>>> error, we should not implicitly convert it to one of the supported
>>>>> values.
>>>>
>>>> Indeed, it is a mistake in my reading of do_tunable_update_val. If the
>>>> value is out of range we should use the default one.
>>>
>>> The code in 'dl-gcs.c' treats any out of range value as an error, but it
>>> seems like 'TUNABLE_GET' returns default value in this case. I'm not
>>> sure when this change happened, it seems to add inconsistency between
>>> string and integer tunables. I think that silent change of behaviour is
>>> not ideal, it should be an error.
>>
>> It was always like that afaik, since the tunable is defind as an integer
>> and it uses the generic code that sets the default value in case of
>> out of range inputs.
>>
>> To proper validate it we will need either to change the generic tunable
>> parsing by either adding callback or an option to error in case of
>> out-of-range; or do it like this patch and parse on arch-specific callback.
> 
> OK, thanks for clarification.
>