Tracking Issue for control-flow enforcement technology (CET)

[abrown]

This is a tracking issue for standardizing the control-flow enforcement technology (CET) flag, cf-protection.

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 flag for cf-protection
• Standardize the cf-protection flag as a -C codegen flag

Unresolved Questions

• Decide whether it is necessary/advisable to merge similar compilation flags (e.g. cf-guard, cf-protection, branch-protection) under a common flag interface
• Decide whether to build the standard libraries with cf-protection by default

If we do build the standard libraries with cf-protection enabled, any assembly code in the libraries will need to be manually checked to see to it that when this flag is set, ENDBR* instructions are inserted in the right places.

Implementation history

See #93439.

[xnox]

In distributions that already elect to build everything with CET enabled by default, we would want to turn it on by default in the rustc compiler and use it for the standard library, and everything by default.

The question is simply as to when. And what can be done to get there. I wonder if we could attempt rebuilding all packages with CET in the distribution to see how far the coverage goes.

[cuviper]

In distributions that already elect to build everything with CET enabled by default, we would want to turn it on by default in the rustc compiler and use it for the standard library, and everything by default.

I don't see any way we could conditionally-default CET for rustup toolchains, but I think the way to go is to make it a rustbuild option, for such distributions to use when building their own Rust toolchain.

[haraldh]

one issue:
#98768

[workingjubilee]

Decide whether it is necessary/advisable to merge similar compilation flags (e.g. cf-guard, cf-protection, branch-protection) under a common flag interface

If these are going to be independent compiler flags and not, say, target features, then yes, it may be a good idea to coalesce these. At least, certainly when the feature is functionally identical (e.g. branch-protection=bti vs. cf-protection=branch).

[tgross35]

Could we get a better summary of the status is here? There is this issue (cc @abrown), a tracking issue with no content for cf-protection stratis-storage/project#418 (cc @mulkieran) and a tracking issue specifically for cf-branch-protection's stabilization (a tracking issue for stabilization seems a bit unusual) #113369 (cc @jacobbramley). Then there's the CFI issue #89653 and RFC rust-lang/rfcs#3296 (cc @rcvalle), which aren't the same thing but cover similar areas.

My feeling is that since cf-protection is just a LLVM flag that has been in the compiler for two years, we can probably stabilize something here if someone makes a proposal about what flags to use, which will go through FCP. But the tracking issues are kind of chaotic, need to figure out what is going on there first

[jacobbramley]

@tgross35 I just updated #113369 with a link to a Zulip thread regarding merging with cf-protection (or not). I'd welcome further input!