Tracking Issue for stabilisation of -Z branch-protection
#113369
Labels
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
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
-Z branch-protection
).-C branch-protection
).Unresolved Questions
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 instd
. 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 usesMin
, 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 ansign-return-address-*
flag that otherwise expect.::Min
also interacts awkwardly with thebkey
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 ofMin
, since LLVM always allows the two to combine, but this is also out of scope of this tracking issue.Implementation history
The text was updated successfully, but these errors were encountered: