Tracking Issue for control-flow enforcement technology (CET) #93754
Description
Activity
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.
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.
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=btivs.cf-protection=branch).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-protectionstratis-storage/project#418 (cc @mulkieran) and a tracking issue specifically forcf-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-protectionis 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 firstReacted by Andrew Brown@tgross35 I just updated #113369 with a link to a Zulip thread regarding merging with
cf-protection(or not). I'd welcome further input!Thanks for the update Jacob, I think following up on Zulip is a good direction to go toward getting this done 👍
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
cf-protectioncf-protectionflag as a-Ccodegen flagUnresolved Questions
cf-guard,cf-protection,branch-protection) under a common flag interfacecf-protectionby defaultIf we do build the standard libraries with
cf-protectionenabled, 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.