================
@@ -591,7 +591,9 @@ obscure_indirect_call_arg_nocfg:
.globl safe_lr_at_function_entry_nocfg
.type safe_lr_at_function_entry_nocfg,@function
safe_lr_at_function_entry_nocfg:
-// CHECK-NOT: safe_lr_at_function_entry_nocfg
+// Due to state being reset after a label, paciasp is reported as
+// a signing oracle - this is a known false positive, ignore it.
+// CHECK-NOT: non-protected call{{.*}}safe_lr_at_function_entry_nocfg
cbz x0, 1f
ret // LR is safe at the start of the
function
1:
----------------
kbeyls wrote:
Thanks, that's useful info to know!
FWIW, my experience on pac-ret is that most code generated by the compiler
follows mostly the same very regular structure, so I'm not surprised that
you're not getting many false positives on llvm-test-suite.
In my experience with pac-ret scanning, you get most false positives when
scanning across a full distribution, on pieces of code that were not generated
by a popular compiler, such as hand-written assembly...
https://github.com/llvm/llvm-project/pull/134146
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
