================
@@ -0,0 +1,175 @@
+##################################
+ Return Address Signing Hardening
+##################################
+
+.. contents::
+ :local:
+
+**************
+ Introduction
+**************
+
+Return Address Signing Hardening is a mitigation against the PACMAN attack,
+which aims to bypass Pointer Authentication on AArch64 targets. The hardening
+mechanism described here is specific to pointer authentication of return
+addresses.
+
+Return Address Signing, also known as Pointer Authentication Code (PAC-RET), is
+a feature devised to protect programs against Return Oriented Programming
(ROP),
+in which attackers may hijack the return address of functions in order to
direct
+execution to malicious code.
+
+PAC-RET can be enabled via different command-line options:
+
+ - ``-mbranch-protection=`` with ``pac-ret``, ``pac-ret+leaf`` or
+ ``standard`` as value.
+ - ``-msign-return-address=`` with ``non-leaf`` or ``all`` as value.
+ - ``-fptrauth-returns``.
+
+More information can be found in :doc:`Pointer Authentication
+<PointerAuthentication>`.
+
+Return Address Signing Hardening is a mechanism to strenghthen Return Address
+Signing against the PACMAN attack in AArch64 targets. It can be enabled with
+``-mharden-pac-ret=load-return-address``.
+
+***************
+ PACMAN attack
+***************
+
+PACMAN is an attack that aims to extract valuable information about pointer
+authentication codes using side-channels in speculative execution.
+
+It is performed with the use of gadgets to try and guess PAC codes. These
+guesses raise no faults because they are done in speculation. By observing the
+effects of the guessed PAC code on the processor's cache, it might be possible
+to determine the valid PAC code for the address to which the attacker wants the
+program to return.
+
+A usual PACMAN gadget looks like this:
+
+.. code:: C
+
+ void function() {
+ ...
+ if (condition)
+ return;
+ ...
+ }
+
+Such code would be compiled to:
+
+.. code:: asm
+
+ paciasp
+ ...
+ cbz w0, .LBB0_2
+ autiasp
+ ret
+ ...
+
+This code segment may be used as a gadget. A speculative execution of this
+segment can happen as follows:
+
+ - If the Link Register (LR) has the right PAC code, ``autiasp`` will
succeed
+ and strip the PAC code out of it. The processor's instruction fetcher
will
+ then bring the code after the return into the cache (that is, the
+ instructions located at the address pointed by LR).
+
+ - If the LR has the wrong PAC code, ``autiasp`` will not succeed and hence
+ will write a predefined error value to the LR's higher bits. Because of
+ this, the instruction fetcher will not bring the code after the return
+ into the cache.
+
+This difference in behavior is what drives the PACMAN attack. An attacker can
+try to guess PAC codes and monitor cache behavior until the code after the
+return is observed to have been brought into the cache.
+
+Details can be found in https://pacmanattack.com.
+
+***********
+ Hardening
+***********
+
+In order to mitigate the PACMAN attack, a hardening mechanism can be enabled
+with ``-mharden-pac-ret=load-return-address``.
+
+.. code:: asm
+
+ paciasp
+ ...
+ cbz w0, .LBB0_2
+ autiasp
+ mov x8, x30
+ xpaclri
+ ldr w30, [x30]
+ ret x8
+ ...
+
+The idea is to always bring the code after the return into cache (the
+instructions located at the address pointed by LR), therefore minimizing the
+difference between a speculative execution with a correct PAC code and with an
+incorrect one.
+
+ - ``autiasp`` performs the authentication step.
+ - ``mov x8, x30`` copies the return address (LR and x30 are synonyms) to a
+ temporary.
+ - ``xpaclri`` strips the PAC code out of the return address in x30.
+ - ``ldr w30, [x30]`` performs a load of the return address in x30.
+ - ``ret x8`` returns to the authenticated return address.
+
+The load operation brings the code into the cache even if the authentication
+step fails. As a consequence, in either case the code is loaded into the cache.
+Furthermore, the return operation uses the original return address before
+stripping, so the return address protection is still kept in place in a normal
+non-speculative execution.
+
+If FEAT_PAUTH is present, the code sequence can use instructions only available
+with said feature with no change in semantics:
+
+.. code:: asm
+
+ autiasp
+ mov x8, x30
+ xpaci x8
+ ldr w8, [x8]
+ ret
+
+*********************
+ Command-line option
+*********************
+
+Return address signing hardening can be enabled at module level with
+``-mharden-pac-ret=load-return-address``. It requires PAC-RET to be enabled at
+module level as well.
----------------
vhscampos wrote:
Done. Originally I wasn't using module flags at all, only relying on function
attributes. But if we want compiler-created functions to have the hardening if
enabled, we need the module flags.
The codegen PR will consume these module flags accordingly.
https://github.com/llvm/llvm-project/pull/176171
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
