[llvm] [BOLT][binary-analysis] Add initial pac-ret gadget scanner (PR #122304)
Peter Smith via llvm-commits
llvm-commits at lists.llvm.org
Fri Jan 10 03:58:17 PST 2025
================
@@ -9,9 +9,168 @@ analyses implemented in the BOLT libraries.
## Which binary analyses are implemented?
-At the moment, no binary analyses are implemented.
+* [Security scanners](#security-scanners)
+ * [pac-ret analysis](#pac-ret-analysis)
-The goal is to make it easy using a plug-in framework to add your own analyses.
+### Security scanners
+
+For the past 25 years, a large numbers of exploits have been built and used in
+the wild to undermine computer security. The majority of these exploits abuse
+memory vulnerabilities in programs, see evidence from
+[Microsoft](https://youtu.be/PjbGojjnBZQ?si=oCHCa0SHgaSNr6Gr&t=836),
+[Chromium](https://www.chromium.org/Home/chromium-security/memory-safety/) and
+[Android](https://security.googleblog.com/2021/01/data-driven-security-hardening-in.html).
+
+It is not surprising therefore, that a large number of mitigations have been
+added to instruction sets and toolchains to make it harder to build an exploit
+using a memory vulnerability. Examples are: stack canaries, stack clash,
+pac-ret, shadow stacks, arm64e, and many more.
+
+These mitigations guarantee a so-called "security property" on the binaries they
+produce. For example, for stack canaries, the security property is roughly that
+a canary is located on the stack between the set of saved variables and set of
+local variables. For pac-ret, it is roughly that there are no writes to the
+register containing the return address after either an authenticating
+instruction or a Branch-and-link instruction.
----------------
smithp35 wrote:
I think "or a Branch-and-and-link instruction is meant to represent the case where the return address remains in the register so it isn't stored into memory?
I tried to think of a way of clarifying, but I couldn't come up with anything better. One possible change is to use the Arm ARM term "Branch with Link" so it is probably best to use that rather than "Branch-and-link".
https://github.com/llvm/llvm-project/pull/122304
More information about the llvm-commits
mailing list