[PATCH 4/4] aarch64: add tests for glibc.cpu.aarch64_bti behaviour

[Adhemerval Zanella Netto]

On 14/11/25 11:58, Yury Khrustalev wrote:
> Hi Adhemerval,
> 
> Thank you for your comments, all will be fixed in the next version of
> this patch series.
> 
> On Mon, Nov 10, 2025 at 12:02:50PM -0300, Adhemerval Zanella Netto wrote:
>>
>> On 31/10/25 16:37, Yury Khrustalev wrote:
>>> Check that the new tunable changes behaviour correctly:
>>>
>>>  * When BTI is enforced, any unmarked binary that is loaded
>>>    results in an error: either an abort or dlopen error when
>>>    this binary is loaded via dlopen.
>>>  * When BTI is not enforced, it is OK to load an unmarked
>>>    binary.
>>> ...
>>>
>>> +tests += \
>>> +  tst-bti-abort-imm \
>>> +  tst-bti-abort-transitive \
>>> +  tst-bti-abort-unprot \
>>> +  tst-bti-dep-prot \
>>> +  tst-bti-dlopen-imm \
>>> +  tst-bti-dlopen-prot \
>>> +  tst-bti-dlopen-transitive \
>>> +  tst-bti-permissive-dlopen \
>>> +  tst-bti-permissive-imm \
>>> +  tst-bti-permissive-transitive \
>>> +  # tests
>>
>> I am seeing these failures when the toolchain does not have 
>> --enable-standard-branch-protection:
>>
>> FAIL: misc/tst-bti-dep-prot
>> FAIL: misc/tst-bti-dlopen-imm
>> FAIL: misc/tst-bti-dlopen-prot
>> FAIL: misc/tst-bti-dlopen-transitive
>>
>> It is because the binaries do not have the BTI property:
> 
> A similar problem exists with some of the GCS tests too. In case when
> the toolchain's CC and LD support BTI (or GCS, etc) but we do not
> enable corresponding branch protection for the Glibc itself, we are
> going to see such test errors simply because libc.so won't have the
> marking.
> 
> Ideally, we need a way to know if branch protection is enabled when
> compiling and linking libc.so and only then activate the corresponding
> tests.
> 
> Perhaps before running the test we could check properties of libc.so
> and let these tests to fail as UNSUPPORTED?

This can be a configure check that enabled Makefile flag.

> 
>> I think we will need to use -mbranch-protection=bti for the aforementioned
>> tests.
> 
> This won't work unfortunately.

I will need to redo my test environment, but this failure in specific was
indeed due the missing support from the binary itself.