[llvm] [BOLT] Gadget scanner: detect authentication oracles (PR #135663)

[Anatoly Trosinenko via llvm-commits]

================
@@ -0,0 +1,739 @@
+// RUN: %clang %cflags -march=armv8.3-a %s -o %t.exe
+// RUN: llvm-bolt-binary-analysis --scanners=pacret %t.exe 2>&1 | FileCheck -check-prefix=PACRET %s
+// RUN: llvm-bolt-binary-analysis --scanners=pauth  %t.exe 2>&1 | FileCheck %s
+
+// The detection of compiler-generated explicit pointer checks is tested in
+// gs-pauth-address-checks.s, for that reason only test here "dummy-load" and
+// "high-bits-notbi" checkers, as the shortest examples of checkers that are
+// detected per-instruction and per-BB.
+
+// PACRET-NOT: authentication oracle found in function
----------------
atrosinenko wrote:

> I'm wondering if authentication oracles should be reported for pac-ret functions too?

This sounds reasonable, even though I'm not sure how likely is to introduce an authentication oracle when only hardening RET instructions. On the other hand, there should not be any authentication oracles in a typical program which is correctly hardened with `pac-ret`, so enabling this scanner should be harmless.

Though, I would rather postpone this discussion not to make the review of this PR even more complicated.

Considering your particular example, this would be reported as an issue, according to the rules implemented in this PR. The unchecked authenticated pointer should be readable by another thread if this thread is stopped right before the RET instruction for some reason :) This could probably be more attackable if some time-consuming operation is performed (in a loop?) between STR and RET. Though, the return instruction should never be executed for some reason (otherwise it would crash on authentication failure), and the authentication oracle uses SP as the descriminator, so this doesn't look practical even if an attacker is able to spawn lots of threads.

https://github.com/llvm/llvm-project/pull/135663