[PATCH v7 14/23] aarch64: Mark objects with GCS property note
Adhemerval Zanella Netto
adhemerval.zanella@linaro.org
Wed Jan 8 16:00:00 GMT 2025
On 08/01/25 12:34, Yury Khrustalev wrote:
> On Tue, Jan 07, 2025 at 01:55:50PM -0300, Adhemerval Zanella Netto wrote:
>>
>>
>>> #define FEATURE_1_AND 0xc0000000
>>> #define FEATURE_1_BTI 1
>>> #define FEATURE_1_PAC 2
>>> +#define FEATURE_1_GCS 4
>>>
>>> /* Add a NT_GNU_PROPERTY_TYPE_0 note. */
>>> #define GNU_PROPERTY(type, value) \
>>> @@ -103,9 +104,9 @@ strip_pac (void *p)
>>> /* Add GNU property note with the supported features to all asm code
>>> where sysdep.h is included. */
>>> #if HAVE_AARCH64_BTI && HAVE_AARCH64_PAC_RET
>>
>> Both HAVE_AARCH64_BTI and HAVE_AARCH64_PAC_RET have configure tests
>> to check if -mbranch-protection={bti,pac-ret} is used. Why do assume
>> GCS support for this case? Should it have a similar check for
>> -mbranch-protection=gcs?
>
> The short answer is no, we don't need a similar check for GCS and the way
> it is currenty implement is correct though not ideal. However, I can see
> how this could be confusing.
>
> First of all, this part only affects hand written assembly and object that
> are compiled from it.
>
> Secondly, checks for BTI and PAC had been historically added this way and
> this might be amended in the future (e.g. we might want to have BTI always
> enabled by default), but this problem is not relevant for GCS.
>
> We want GCS markings to be always enabled simply because it doesn't break
> anything and is convenient because we don't want to support every possible
> combination (it would have no practical value). Having GCS added as above
> is the simplest possible solution with no downsides (except for it looking
> a bit confusing at first glance).
Fair enough, should it be enable regardless of HAVE_AARCH64_BTI/HAVE_AARCH64_PAC_RET
then?
More information about the Libc-alpha
mailing list