Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Issue for stabilisation of -Z branch-protection #113369

Open
1 of 3 tasks
jacobbramley opened this issue Jul 5, 2023 · 1 comment
Open
1 of 3 tasks

Tracking Issue for stabilisation of -Z branch-protection #113369

jacobbramley opened this issue Jul 5, 2023 · 1 comment
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC

Comments

@jacobbramley
Copy link
Contributor

jacobbramley commented Jul 5, 2023

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

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

@xuyoujun
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC
Projects
None yet
Development

No branches or pull requests

2 participants