The FEAT_PAuth_LR feature introduced with Armv9.5-A introduces new instructions to sign and authenticate the return address that use the PC value as an additional modifier. It also introduces a Hint space instruction called PACM that can modify the behaviour of existing hint space instructions. Quoting from the Arm ARM
PACM is intended to be executed immediately before a PACIASP, PACIBSP, AUTIASP, AUTIBSP, RETAA, RETAB, AUTIA1716, AUTIB1716, PACIA1716, or PACIB1716 instruction, to extend the operation of those instructions to take a second diversifier.
Unfortunately, for the ABI, PACM does not always extend the operation of the hint instructions. A hardware implementation may have a "trivial implementation", and the OS may control whether PACM affects the PSATE.PACM.
This means that a PACM followed by PACIASP may result in a different result than a single PACIASPPC instruction, this means that for a single address we have to use hint-space for both signing and authentication, or both non-hint-space. For example we must match PACM, PACIASP with PACM, AUTIASP; we cannot sign with PACIASPPC and authenticate with PACM, AUTIASP.
While compiled-code will always use matching pairs of hint-space or non-hint space instructions, in a program some functions may use hint-space and some may use non-hint-space instructions. A stack-unwinder may therefore encounter some return addresses signed with hint-space and some with non-hint-space instructions. To correctly unwind the stack it will need to know whether a location was signed with hint-space or non-hint-space instructions.
This will need an addition to aadwarf64 (details TBD), that will need to be developed alongside an unwinder fix.
The FEAT_PAuth_LR feature introduced with Armv9.5-A introduces new instructions to sign and authenticate the return address that use the PC value as an additional modifier. It also introduces a Hint space instruction called PACM that can modify the behaviour of existing hint space instructions. Quoting from the Arm ARM
Unfortunately, for the ABI, PACM does not always extend the operation of the hint instructions. A hardware implementation may have a "trivial implementation", and the OS may control whether PACM affects the PSATE.PACM.
This means that a PACM followed by PACIASP may result in a different result than a single PACIASPPC instruction, this means that for a single address we have to use hint-space for both signing and authentication, or both non-hint-space. For example we must match PACM, PACIASP with PACM, AUTIASP; we cannot sign with PACIASPPC and authenticate with PACM, AUTIASP.
While compiled-code will always use matching pairs of hint-space or non-hint space instructions, in a program some functions may use hint-space and some may use non-hint-space instructions. A stack-unwinder may therefore encounter some return addresses signed with hint-space and some with non-hint-space instructions. To correctly unwind the stack it will need to know whether a location was signed with hint-space or non-hint-space instructions.
This will need an addition to aadwarf64 (details TBD), that will need to be developed alongside an unwinder fix.