[PATCH v8 00/20] aarch64: Add support for Guarded Control Stack extension

[Adhemerval Zanella Netto]

On 16/01/25 14:07, Yury Khrustalev wrote:
> On Thu, Jan 16, 2025 at 01:51:49PM -0300, Adhemerval Zanella Netto wrote:
>>
>> Right, it is clear now and sorry for the confusion. Maybe expanding the tunables.texi
>> with this very explanation, specially for aarch64_gcs_policy=1.
> 
> This makes sense, I will add more detailed explanation to the manual.

Thanks, I think you replicate this explanation on the manual it would be
really helpful.

> 
>>>>> Policy 1 can switch off GCS but never via dlopen.
>>>>
>>>> I still think we can just make it only one tunable, since with aarch64_gcs=0
>>>> policy does not matter (so it can be policy=0).
>>>
>>> Certainly it's option to use one tunable. With two tunables we use one to
>>> turn GCS on or off and we use another to select desired behaviour if GCS is
>>> enabled. Now it's a matter of time and testing though. We didn't get any
>>> negative feedback about two tunables so far.
>>
>> Do you plan to expand or add additional semantic to aarch64_gcs=0:aarch64_gcs_policy=N?
>> Because still really confusing to have two tunables, where one is just a switch
>> to second.
> 
> I'm note sure if more policies will be added. If aarch64_gcs=0, then policy is not
> applicable. I will change the implementation to one tunable aarch64_gcs:
> 
>  - 0: disabled (use case a)
>  - 1: enforced: check markings and fail if any binary is not marked (use case d)
>  - 2: optional: check markings and don't enable GCS is any binaries are unmarked (use case c)
>  - 3: always: enable GCS, markings are ignored (use case b)
> 
> If GCS is enabled and markings are not ignored during dlopen() and binary being loaded is not marked,
> then it's abort (this is applicable to aarch64_gcs = 1 and 2).
> 
> Does this make sense?

Now it does, sorry for the noise (I has some wrong assumption on how the code
was suppose to work).