================
@@ -1922,12 +1922,20 @@ class _LIBUNWIND_HIDDEN Registers_arm64 {
   void
   loadAndAuthenticateLinkRegister(reg_t inplaceAuthedLinkRegister,
                                   link_reg_t *referenceAuthedLinkRegister) {
-    // If we are in an arm64/arm64e frame, then the PC should have been signed
-    // with the SP
-    *referenceAuthedLinkRegister =
-      (uint64_t)ptrauth_auth_data((void *)inplaceAuthedLinkRegister,
-                                  ptrauth_key_return_address,
-                                  _registers.__sp);
+    // In arm64e or pauthtest ABI frame, the PC should have been signed with
+    // the SP - resign it with a schema that can be represented with __ptrauth.
+    //
+    // Call the resign builtin explicitly instead of relying on implicit 
signing
+    // of the authenticated value on assignment to 
*referenceAuthedLinkRegister,
+    // as the latter results in comparison against 0 between auth and sign
+    // operations.
----------------
atrosinenko wrote:

> Anyway, could you file a bug on me for this, I don't believe that we should 
> need to null check after the auth, but there are all sorts of weird semantics 
> to worry about, but should be doable.

Is the existing behavior of Clang incorrect? This looks rather natural with 
these two assumptions:
* `ptrauth_auth_data` is directly translated to a target-specific authentication
* extra care is taken by Clang to keep `nullptr`s represented with all zero 
bits when dealing with `__ptrauth`-qualified variables

This way, the existing implementation of `loadAndAuthenticateLinkRegister` is 
lowered as expected. First, `inplaceAuthedLinkRegister` is explicitly 
authenticated as requested by the programmer, producing _a value_. Then, an 
_arbitrary value_ is assigned to a `__ptrauth`-qualified variable, which 
according to Clang has the semantic "sign if non-zero, assign literal zero 
otherwise".

PS: `__ptrauth(..., "authenticates-null-values")` looks great for such use 
cases!

https://github.com/llvm/llvm-project/pull/183603
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to