Tracking Issue for stabilisation of -Z branch-protection

[jacobbramley]

This is a tracking issue for standardising the -Z branch-protection=... codegen option, which enables control-flow integrity measures using Armv8.3 pointer authentication and/or Armv8.5 branch target identification on AArch64.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the unstable option (-Z branch-protection).
• Stabilization PR for the stable option (-C branch-protection).

Unresolved Questions

• Should this first be merged with cf-protection? (Zulip)

Future Work

Stabilisation of branch-protection is a necessary step for making these technologies straightforward to use, but there are other obstacles beyond the codegen option itself:

std

Deploying these CFI technologies typically requires all code in a process to be compiled with similar mitigations. For example, today you probably also need to use the unstable build-std to rebuild the standard library accordingly, otherwise ROP-style gadgets may still be present in std. One way to improve this for users would be to offer a pre-built standard library with (for example) branch-protection=pac-ret,bti, in addition to the baseline. However, such a mechanism requires further work, and is out of scope of this tracking issue.

LTO and module flag combination

Module flags in LLVM 14 and 15 behave quite differently (e.g. during LTO). LLVM 14 uses Error, so all modules must match. LLVM 15 uses Min, so module flags are downgraded to the lowest value, without notification. As a result, it's quite easy to accidentally disable these flags process-wide with LTO builds, for example by linking a single module that lacks an sign-return-address-* flag that otherwise expect. ::Min also interacts awkwardly with the bkey configuration, which isn't inherently ordered.

We should address this, but it's really an LLVM concern rather than a Rust one. Rust could provide an additional option to use the Warning module flag instead of Min, since LLVM always allows the two to combine, but this is also out of scope of this tracking issue.

Implementation history

• Add codegen option for branch protection and pointer authentication on AArch64 #88354
• No branch protection metadata unless enabled #93516
• Check AArch64 branch-protection earlier in the pipeline. #105421
• Correct branch-protection ModFlagBehavior for Aarch64 on LLVM-15 #105932

[xuyoujun]

pac and bti are very important feature on AArch64. Android using a mount of rust code, but Android recommend enable pac and bti

[SparrowLii]

This feature is very important for products which run on aarch64.

When will this feature be stabilized? Are there any other issues that need to be addressed?

[jacobbramley]

This feature is very important for products which run on aarch64.

When will this feature be stabilized? Are there any other issues that need to be addressed?

I proposed a unified CLI (merging with cf-protection) shortly after opening this tracking issue. A unified approach was requested on Zulip, if I remember correctly.

• The question of ABI compatibility, and what that really means for these CFI options, probably affects how we present these flags. The broader issue has been under investigation by @RalfJung and others. We need to re-evaluate this proposal taking those outcomes into account, but it's likely to amount to renaming and filtering of proposed options. They won't be called abi-variant!
• The proposal includes a mechanism for future expansion without instant stabilisation, but (assuming that I understood correctly) @davidtwco recently told me that there's an existing mechanism for that.
• @mrkajetanp submitted a PR that makes cc-rs forward these flags. (That's important for std.)

A few people raised concerns about having a stable flag that doesn't actually work out of the box, since effective use also requires the build-std Cargo flag. @adamgemmell is focussing on that, but it's by far the largest piece of work blocking this stabilisation.

There's potentially a justification for stabilising branch-protection for environments that are supplying their own std anyway (or aren't using Cargo). We didn't explore that at the time, but if there's a way to stabilise it but have it fail in a useful way if the available std doesn't match, we could pursue that.

It's likely that @davidtwco will oversee this in the future.