[llvm-branch-commits] [llvm] [BOLT] Gadget scanner: add less strict version of tail call checker (PR #188974)

[Harald van Dijk via llvm-branch-commits]

hvdijk wrote:

> As far as I remember from the [discussion on Phabricator](https://reviews.llvm.org/D156716), it is important to be able to opt-out of explicit checking of the result of LR authentication. After all, inserting an expensive instruction sequence would thwart one of the features of tail calls, their efficiency.

We're definitely in agreement on the code generation side, but I don't know if that should affect the analysis side. As you say it would be too costly to generate code that handles this on some platforms, but from BOLT's perspective, if Clang is intentionally generating code that results in a vulnerable `ret` (even if indirectly), and BOLT is asked to analyse a binary to find vulnerable `ret`s, I still expect that to be reported.

> The "basic" level of tail call checker introduced in this PR is intended to catch missing minimal pac-ret mitigations when it comes to tail-calling functions.

But it also makes it so that `--scanners=ptrauth-pac-ret` only enables that basic level, right? That's an option that I would have expected to enable the full level.

> Oh, I meant the hackish way to carve the set of checks validating minimal pac-ret hardening for both regular and tail-calling functions: "let's additionally enable ptrauth-tail-calls but inhibit reports for not explicitly checking the results of authentication by promising we have FEAT_FPAC".

Ah, right, thanks. Yeah, using `--auth-traps-on-failure` when the target doesn't have `FEAT_FPAC` just to silence warnings is a bit questionable, but it is kind of what the user is requesting and IMO better conveys the intent. The generated code is safe only on `FEAT_FPAC` targets, but also runs on non-`FEAT_FPAC` targets. If the user doesn't care that there's a potential vulnerability on non-`FEAT_FPAC` targets, having the user run the analysis with `--auth-traps-on-failure` doesn't feel like a bad thing?

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