On 1/4/24 16:10, Jarek Prokop wrote:
On 1/4/24 10:47, Florian Weimer wrote:
> * Jarek Prokop:
>
>> This spawns a few questions for me:
>> 1. Since [1] the `-mbranch-protection=pac-ret` is needed in both
>> CFLAGS and ASFLAGS, I am unsure how it interacts with the Fedora
>> defaults,
>> I see default CFLAGS contain `-mbranch-protection=standard` and the
>> flag with pac-ret seems to be appended to libruby.so in the case of
>> the upstream fix [2].
>>
>> >From what I understand, it shouldn't cause problems to have these 2
>> flags at the same time on the correct compilation artifacts, is that
>> correct?
> I wouldn't use both flags at the same time because the meaning is
> unclear. Is BTI still enabled if you do that?
Not sure how I would check that.
By compiling on an ARM machine, duh!
Compiling with file test.c like this:
~~~
$ cat test.c
#include <stdio.h>
#include <stddef.h>
int main() {
printf("%d", __ARM_FEATURE_BTI_DEFAULT);
printf("%d", __ARM_FEATURE_PAC_DEFAULT);
return 0;
}
$ gcc -mbranch-protection=standard -mbranch-protection=pac-ret test.c
test.c: In function ‘main’:
test.c:5:18: error: ‘__ARM_FEATURE_BTI_DEFAULT’ undeclared (first use in
this function)
5 | printf("%d", __ARM_FEATURE_BTI_DEFAULT);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
test.c:5:18: note: each undeclared identifier is reported only once for
each function it appears in
~~~
So it seems anything related to BTI gets actually skipped in the
upstream Context.S file, since their only option is for `=pac-ret`.
And for completenes, same file, but with =standard:
~~~
$ gcc -mbranch-protection=standard test.c
$ ./a.out
11
~~~
tl;dr No, it doesn't seem to remain enabled if this double definition is
done.
Thanks,
Jarek