[OpenMP][AArch64] Fix branch protection in microtasks (#102317)

[tuliom]

Start __kmp_invoke_microtask with PACBTI in order to identify the function as a valid branch target. Before returning, SP is authenticated.
Also add the BTI and PAC markers to z_Linux_asm.S.

With this patch, libomp.so can now be generated with DT_AARCH64_BTI_PLT when built with -mbranch-protection=standard.

The implementation is based on the code available in compiler-rt.

(cherry picked from commit 0aa22dc)

[tuliom]

@tru Could you take a look at this backport PR for release/19.x, please?

[tru]

@DanielKristofKiss can you have a look if we want to backport this to 19.x? At this point in the release process we only want to take regressions and serious bugs. It was hard for me to understand if this falls under that.

[DanielKristofKiss]

Some Distros(e.g. Fedora) are build by default branch-protection=standard.
Without this patch every application and library that links libopenmp.a will not be protected with BTI ( CFI protection for JOP attacks)
Also libopenmp.so won't be protected as not all file is BTI compatible.
So in security view this is an issue.
Not a regression as this was the case in previous releases.
Not a bug, as code will work just won't be CFI protected.
There are systems out there with BTI as of today with such a distro.

@tuliom do you have usecase for this?
@tru Change is simple and straightforward. I support the backport but leave it up to you.

HTH

[tru]

Ok - I am always open to accept things that improve security unless the risk is huge. But it sounds like this will only affect applications that are linking to openmp? Do you see any other risks of accepting this now?

[tuliom]

@tuliom do you have usecase for this?

My usecase is indeed having Fedora and CentOS/RHEL to be fully protected against JOP attacks.
The lack of BTI support causes annocheck to report this issue, e.g. https://issues.redhat.com/browse/RHEL-50807

[tuliom]

But it sounds like this will only affect applications that are linking to openmp?

Correct.

Do you see any other risks of accepting this now?

IMHO, no. But if you prefer to delay this to 19.1.1, that looks good to me.

[github-actions]

@tuliom (or anyone else). If you would like to add a note about this fix in the release notes (completely optional). Please reply to this comment with a one or two sentence description of the fix. When you are done, please add the release:note label to this PR.