[PATCH v7 18/23] aarch64: Handle GCS marking

[Adhemerval Zanella Netto]

On 08/01/25 10:59, Yury Khrustalev wrote:
> On Tue, Jan 07, 2025 at 02:05:46PM -0300, Adhemerval Zanella Netto wrote:
>>
>>> +static void
>>> +fail (struct link_map *l, const char *program)
>>> +{
>>> +  if (program && program[0])
>>> +    _dl_fatal_printf ("%s: %s: %s\n", program, l->l_name, N_("not GCS compatible"));
>>> +  else if (program)
>>> +    _dl_fatal_printf ("%s\n", N_("not GCS compatible"));
>>> +  else
>>> +    _dl_signal_error (0, l->l_name, "dlopen", N_("not GCS compatible"));
>>> +}
>>
>> I don't think N_ would make a difference here, it is not support on loader
>> and adding on the translation database does not add much without revamping
>> how to translation during program loading.
> 
> Makes sense, thanks. I'll remove "N_".
> 
>>> +static void
>>> +check_gcs (struct link_map *l, const char *program)
>>> +{
>>> +  bool for_dlopen = program == NULL;
>>> +  if (!l->l_mach.gcs)
>>> +    {
>>> +      if (GLRO(dl_aarch64_gcs_policy) == 2 || for_dlopen)
>>> +	fail (l, program);
>>> +      if (GLRO(dl_aarch64_gcs_policy) == 1)
>>> +	GL(dl_aarch64_gcs) = 0;
>>> +      else
>>> +	unsupported ();
>>> +    }
>>> +}
>>> +
>>
>> This requires to update the glibc.cpu.aarch64_gcs_policy entry at 
>> manual/tunables.texi with the description of what each value represents.
> 
> Right now GCS tunable names are reserved in the manual. When corresponding
> Linux kernel functionality has been released, there will be another patch
> for Glibc that will add the description of both GCS tunables. At this point
> these tunables will become "public". This will likely be after the upcoming
> Glibc release.

Ok, but this code is already defining the logic of how aarch64_gcs_policy
works and when a user glibc on a GCS enabled kernel the tunable will be
enacted.  I still think we need to document the current semantic, the
reserved rationale would make sense if the tunable was not enacted.