================
@@ -126,6 +130,36 @@ _LIBUNWIND_HIDDEN int __unw_set_reg(unw_cursor_t *cursor,
unw_regnum_t regNum,
// First, get the FDE for the old location and then update it.
co->getInfo(&info);
co->setInfoBasedOnIPRegister(false);
+
+#if __has_feature(ptrauth_calls)
+ // It is only valid to set the IP within the current function.
+ // This is important for ptrauth, otherwise the IP cannot be correctly
+ // signed.
+ unw_word_t stripped_value =
+ (unw_word_t)ptrauth_strip((void *)value, ptrauth_key_return_address);
+ (void)stripped_value;
+ assert(stripped_value >= info.start_ip && stripped_value <= info.end_ip);
+#endif
+
+ pint_t sp = (pint_t)co->getReg(UNW_REG_SP);
+
+#if __has_feature(ptrauth_calls)
+ {
+ // PC should have been signed with the sp, so we verify that
+ // roundtripping does not fail.
+ pint_t pc = (pint_t)co->getReg(UNW_REG_IP);
+ if (ptrauth_auth_and_resign((void *)pc, ptrauth_key_return_address, sp,
+ ptrauth_key_return_address,
+ sp) != (void *)pc) {
+ _LIBUNWIND_LOG("Bad unwind through arm64e (0x%llX,
0x%llX)->0x%llX\n",
----------------
kovdan01 wrote:
While FPAC does the job and with that being enabled, we do not reach this
logging, it's not true when we do not have FPAC :) We cannot guarantee that
it's present. And anyway, it's better to use more generic messages in places
which are not specific for arm64e.
I suggest to look through the PR and think of replacing mentions of arm64e with
smth describing arbitrary ptrauth-enabled platforms (where applicable).
I can help with that when all the functional issues with this PR are resolved.
https://github.com/llvm/llvm-project/pull/143230
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
