aarch64: support BTI and pointer authentication in assembly

[andrew]

Summary

This change adds optional support for

• Armv8.3-A Pointer Authentication (PAuth) and
• Armv8.5-A Branch Target Identification (BTI)

features to the perl scripts.

Both features can be enabled with additional compiler flags.
Unless any of these are enabled explicitly there is no code change at
all.

The extensions are briefly described below. Please read the appropriate
chapters of the Arm Architecture Reference Manual for the complete
specification.

Scope

This change only affects generated assembly code.

Armv8.3-A Pointer Authentication

Pointer Authentication extension supports the authentication of the
contents of registers before they are used for indirect branching
or load.

PAuth provides a probabilistic method to detect corruption of register
values. PAuth signing instructions generate a Pointer Authentication
Code (PAC) based on the value of a register, a seed and a key.
The generated PAC is inserted into the original value in the register.
A PAuth authentication instruction recomputes the PAC, and if it matches
the PAC in the register, restores its original value. In case of a
mismatch, an architecturally unmapped address is generated instead.

With PAuth, mitigation against ROP (Return-oriented Programming) attacks
can be implemented. This is achieved by signing the contents of the
link-register (LR) before it is pushed to stack. Once LR is popped,
it is authenticated. This way a stack corruption which overwrites the
LR on the stack is detectable.

The PAuth extension adds several new instructions, some of which are not
recognized by older hardware. To support a single codebase for both pre
Armv8.3-A targets and newer ones, only NOP-space instructions are added
by this patch. These instructions are treated as NOPs on hardware
which does not support Armv8.3-A. Furthermore, this patch only considers
cases where LR is saved to the stack and then restored before branching
to its content. There are cases in the code where LR is pushed to stack
but it is not used later. We do not address these cases as they are not
affected by PAuth.

There are two keys available to sign an instruction address: A and B.
PACIASP and PACIBSP only differ in the used keys: A and B, respectively.
The keys are typically managed by the operating system.

To enable generating code for PAuth compile with
-mbranch-protection=<mode>:

• standard or pac-ret: add PACIASP and AUTIASP, also enables BTI (read below)
• pac-ret+b-key: add PACIBSP and AUTIBSP

Armv8.5-A Branch Target Identification

Branch Target Identification features some new instructions which
protect the execution of instructions on guarded pages which are not
intended branch targets.

If Armv8.5-A is supported by the hardware, execution of an instruction
changes the value of PSTATE.BTYPE field. If an indirect branch
lands on a guarded page the target instruction must be one of the
BTI <jc> flavors, or in case of a direct call or jump it can be any
other instruction. If the target instruction is not compatible with the
value of PSTATE.BTYPE a Branch Target Exception is generated.

In short, indirect jumps are compatible with BTI <j> and <jc> while
indirect calls are compatible with BTI <c> and <jc>. Please refer to the
specification for the details.

Armv8.3-A PACIASP and PACIBSP are implicit branch target
identification instructions which are equivalent with BTI c or BTI jc
depending on system register configuration.

BTI is used to mitigate JOP (Jump-oriented Programming) attacks by
limiting the set of instructions which can be jumped to.

BTI requires active linker support to mark the pages with BTI-enabled
code as guarded. For ELF64 files BTI compatibility is recorded in the
.note.gnu.property section. For a shared object or static binary it is
required that all linked units support BTI. This means that even a
single assembly file without the required note section turns-off BTI
for the whole binary or shared object.

The new BTI instructions are treated as NOPs on hardware which does
not support Armv8.5-A or on pages which are not guarded.

To insert this new and optional instruction compile with
-mbranch-protection=standard (also enables PAuth) or +bti.

When targeting a guarded page from a non-guarded page, weaker
compatibility restrictions apply to maintain compatibility between
legacy and new code. For detailed rules please refer to the Arm ARM.

Compiler support

Compiler support requires understanding '-mbranch-protection=<mode>'
and emitting the appropriate feature macros (ARM_FEATURE_BTI_DEFAULT
and ARM_FEATURE_PAC_DEFAULT). The current state is the following:

---

Compiler	-mbranch-protection	Feature macros

+----------+---------------------+--------------------+

clang	9.0.0	11.0.0

+----------+---------------------+--------------------+

| gcc | 9 | expected in 10.1+ |

Available Platforms

Arm Fast Model and QEMU support both extensions.

https://developer.arm.com/tools-and-software/simulation-models/fast-models
https://www.qemu.org/

Implementation Notes

This change adds BTI landing pads even to assembly functions which are
likely to be directly called only. In these cases, landing pads might
be superfluous depending on what code the linker generates.
Code size and performance impact for these cases would be negligible.

Interaction with C code

Pointer Authentication is a per-frame protection while Branch Target
Identification can be turned on and off only for all code pages of a
whole shared object or static binary. Because of these properties if
C/C++ code is compiled without any of the above features but assembly
files support any of them unconditionally there is no incompatibility
between the two.

Useful Links

To fully understand the details of both PAuth and BTI it is advised to
read the related chapters of the Arm Architecture Reference Manual
(Arm ARM):
https://developer.arm.com/documentation/ddi0487/latest/

Additional materials:

"Providing protection for complex software"
https://developer.arm.com/architectures/learn-the-architecture/providing-protection-for-complex-software

Arm Compiler Reference Guide Version 6.14: -mbranch-protection
https://developer.arm.com/documentation/101754/0614/armclang-Reference/armclang-Command-line-Options/-mbranch-protection?lang=en

Arm C Language Extensions (ACLE)
https://developer.arm.com/docs/101028/latest

Addional Notes

This patch is a copy of the work done by Tamas Petz in boringssl. It
contains the changes from the following commits:

aarch64: support BTI and pointer authentication in assembly

Change-Id: I4335f92e2ccc8e209c7d68a0a79f1acdf3aeb791
URL: https://boringssl-review.googlesource.com/c/boringssl/+/42084

aarch64: Improve conditional compilation

Change-Id: I14902a64e5f403c2b6a117bc9f5fb1a4f4611ebf
URL: https://boringssl-review.googlesource.com/c/boringssl/+/43524

aarch64: Fix name of gnu property note section

Change-Id: I6c432d1c852129e9c273f6469a8b60e3983671ec
URL: https://boringssl-review.googlesource.com/c/boringssl/+/44024

Change-Id: I2d95ebc5e4aeb5610d3b226f9754ee80cf74a9af

Reviewed-by: Paul Dale <[e-mail]>
Reviewed-by: Tomas Mraz <[e-mail]>
(Merged from https://github.com/openssl/openssl/pull/16674)

[andrew]

This is a backport of https://github.com/openssl/openssl/commit/19e277dd19f2897f6a7b7eb236abe46655e575bf

[khorben_defora.org]

FWIW this patch does not conflict with the import of OpenSSL 3.0.11 that I am currently preparing (vendor import in D41943).

[khorben_defora.org]

We may also want to consider 40c24d74deaad8a0ad7566a68ea5ea757bc3ccef as well, from OpenSSL's Git repository:

commit 40c24d74deaad8a0ad7566a68ea5ea757bc3ccef
Author: David Benjamin <[e-mail]>
Date:   Wed Dec 29 13:05:12 2021 -0500

    Don't use __ARMEL__/__ARMEB__ in aarch64 assembly

    GCC's __ARMEL__ and __ARMEB__ defines denote little- and big-endian arm,
    respectively. They are not defined on aarch64, which instead use
    __AARCH64EL__ and __AARCH64EB__.

    However, OpenSSL's assembly originally used the 32-bit defines on both
    platforms and even define __ARMEL__ and __ARMEB__ in arm_arch.h. This is
    less portable and can even interfere with other headers, which use
    __ARMEL__ to detect little-endian arm.

    Over time, the aarch64 assembly has switched to the correct defines,
    such as in 32bbb62ea634239e7cb91d6450ba23517082bab6. This commit
    finishes the job: poly1305-armv8.pl needed a fix and the dual-arch
    armx.pl files get one more transform to convert from 32-bit to 64-bit.

    (There is an even more official endianness detector, __ARM_BIG_ENDIAN in
    the Arm C Language Extensions. But I've stuck with the GCC ones here as
    that would be a larger change.)

    Reviewed-by: Matt Caswell <[e-mail]>
    Reviewed-by: Tomas Mraz <[e-mail]>
    Reviewed-by: Paul Dale <[e-mail]>
    Reviewed-by: Bernd Edlinger <[e-mail]>
    (Merged from https://github.com/openssl/openssl/pull/17373)

It should not affect the possibility to accept this change though.

[khorben_defora.org]

Can you review the comment I added about crypto/sha/asm/keccak1600-armv8.pl?

crypto/openssl/crypto/sha/asm/keccak1600-armv8.pl

129

Here the adr $C[2],iotas and AARCH64_SIGN_LINK_REGISTER lines are flipped when compared to the same file in 3.2.0-alpha1. I am not familiar enough with PAuth/BTI in order to determine if this is a problem but it seems wrong to me.

[khorben_defora.org]

I found information confirming my doubts about the keccak code.

crypto/openssl/crypto/sha/asm/keccak1600-armv8.pl

129

According to 3a23f01268ec47bf3423b849cc226be220745522 it looks like this would be the right thing to do:

commit 3a23f01268ec47bf3423b849cc226be220745522
Author: Tom Cosgrove <[e-mail]>
Date:   Mon Feb 7 14:44:56 2022 +0000

    aarch64: fix branch target indications in arm64cpuid.pl and keccak1600
    
    Add missing AARCH64_VALID_CALL_TARGET to armv8_rng_probe(). Also add
    these to the functions defined by gen_random(), and note that this Perl
    sub prints the assembler out directly, not going via the $code xlate
    mechanism (and therefore coming before the include of arm_arch.h). So
    fix this too.
    
    In KeccakF1600_int, AARCH64_SIGN_LINK_REGISTER functions as
    AARCH64_VALID_CALL_TARGET on BTI-only builds, so it needs to come before
    the 'adr' line.
    
    Change-Id: If241efe71591c88253a3e36647ced00300c3c1a3
    
    Reviewed-by: Tomas Mraz <[e-mail]>
    Reviewed-by: Paul Dale <[e-mail]>
    (Merged from https://github.com/openssl/openssl/pull/17653)

[...]

diff --git a/crypto/sha/asm/keccak1600-armv8.pl b/crypto/sha/asm/keccak1600-armv8.pl
index cf54b62c63..40f7aa7a69 100755
--- a/crypto/sha/asm/keccak1600-armv8.pl
+++ b/crypto/sha/asm/keccak1600-armv8.pl
@@ -126,8 +126,8 @@ $code.=<<___;
 .type  KeccakF1600_int,%function
 .align 5
 KeccakF1600_int:
-       adr     $C[2],iotas
        AARCH64_SIGN_LINK_REGISTER
+       adr     $C[2],iotas
        stp     $C[2],x30,[sp,#16]              // 32 bytes on top are mine
        b       .Loop
 .align 4

[andrew]

crypto/openssl/crypto/sha/asm/keccak1600-armv8.pl

129

That is fixed in https://github.com/openssl/openssl/commit/3a23f01268ec47. I can import that change too, however my plan is to enable BTI in the kernel first where this isn't used. I don't plan on changing this commit as it's a direct import of an upstream change.

[khorben_defora.org]

Sounds good to me then!