aarch64: enable PAC and BTI

[billatarm]

Enable Pointer Authentication Codes (PAC) and Branch Target Identification (BTI) support for ARM 64 targets.

PAC works by signing the LR with either an A key or B key and verifying the return address. There are quite a few instructions capable of doing this, however, the Linux ARM ABI is to use hint compatible instructions that can be safely NOP'd on older hardware and can be assembled and linked with older binutils. This limits the instruction set to paciasp, pacibsp, autiasp and autibsp. Instructions prefixed with pac are for signing and instructions prefixed with aut are for signing. Both instructions are then followed with an a or b to indicate which signing key they are using. The keys can be controlled using -mbranch-protection=pac-ret for the A key and
-mbranch-protection=pac-ret+b-key for the B key.

BTI works by marking all call and jump positions with bti c and bti j instructions. If execution control transfers to an instruction other than a BTI instruction, the execution is killed via SIGILL. Note that to remove one instruction, the aforementioned pac instructions will also work as a BTI landing pad for bti c usages.

For BTI to work, all object files linked for a unit of execution, whether an executable or a library must have the GNU Notes section of the ELF file marked to indicate BTI support. This is so loader/linkers can apply the proper permission bits (PROT_BRI) on the memory region.

PAC can also be annotated in the GNU ELF notes section, but it's not required for enablement, as interleaved PAC and non-pac code works as expected since it's the callee that performs all the checking.

[Neustradamus]

@ip7z: What do you think about this PR?

[billatarm]

bump

[gyurix]

Security-hardening direction is good, but implementation looks incomplete.

Adding GNU property notes in one assembly file does not show whole-binary PAC/BTI coverage by itself. There are no matching build-flag/toolchain changes here, and no proof from linked binaries that final artifacts get desired properties.

Merge readiness: 5/10. Before merge: show readelf/linked-binary evidence, explain interaction with other objects, and include whatever build/docs changes are required for end-to-end enablement.

[billatarm]

Security-hardening direction is good, but implementation looks incomplete.

Adding GNU property notes in one assembly file does not show whole-binary PAC/BTI coverage by itself.

You don't need to do anything for C files, it just works. It's only the one asm file, and per the comment:

 ; Assembly:
 ;  Since this code base has no indirect calls or jumps to any assembly,
 ;  there is no need to modify the source code with bti or pac instructions.

There are no matching build-flag/toolchain changes here, and no proof from linked binaries that final artifacts get desired properties.

TL;DR Exactly where would I add these?

These makefiles are pretty non-standard and don't respect the standard CFLAGS or CXXFLAGS env vars. I am not really sure where it would be appropriate to add any flags. Additionally, over in Fedora, we just patch the Makefile to support these env vars for building the package.

The specific flag to add would be: -mbranch-protection=standard.

Merge readiness: 5/10. Before merge: show readelf/linked-binary evidence

Sure

explain interaction with other objects

What exactly would I describe that isn't in the commit message or is that you want that in some text file under DOC?

and include whatever build/docs changes are required for end-to-end enablement.

Sure