Tracking issue for `-Z control_flow_guard`

[ajpaverd]

This is a tracking issue for the flag to enable Windows Control Flow Guard, added in #68180.

[ajpaverd]

The config.toml option to build libstd with Control Flow Guard checks was added in #68824.

[nikomatsakis]

So @rylev reached out to me to ask about stabilization as well as the possibility of enabling this option by default for the stdlib when built on Windows (at least with msvc, I imagine).

I would like to see this move forward, as it seems like a useful option with important safety implications.

What I think we want is the following

• A PR adding user-facing documentation to the unstable book
  • What does the feature do?
  • Benefits, drawbacks of enabling it
  • Links to other tooling and related explanations (LLVM, etc)
• A write-up describing what the background and motivation for this feature; this overlaps somewhat with the user-facing documentation but is probably in more depth:
  • Some links and background on what the flag does
  • Benefits, drawbacks of using it
  • Precedent for how other compilers behave (is this option on by default with msvc? clang? etc? is it used in other major projects?)
  • If we want to argue for making it the default, I would include some arguments for why this makes sense and what the drawbacks might be, and any relevant precedent
• Once we have that, we can nominate the issue and potentially move to FCP (as a user-facing change, I believe this requires an FCP at least; I'd not be opposed to an RFC, but it may not be necessary).

In terms of the decision makers:

• Stabilizing the flag seems like a @rust-lang/compiler decision
• But I'm not sure which team(s) make the decisions about "what options to use when building the standard library". @rust-lang/compiler, @rust-lang/libs, perhaps? But it's not really the "core competency" for either team as I think of it. I'll cc @Mark-Simulacrum (release team) to get their take on that question too. =)

[Mark-Simulacrum]

Yeah, I think that's about the right set of people. In this particular case I imagine we'd treat this similarly to stack guards and so forth on other platforms (at a high level, my understanding is that this is similar, just more pervasive -- related to control flow vs. stack overflows).

With regards to whether or not to stabilize/add this to std's flags I would definitely need to read a write up as you've suggested. :)

[nikomatsakis]

@ajpaverd do you think you'd be up for producing the write-up that I referenced?

[ajpaverd]

@ajpaverd do you think you'd be up for producing the write-up that I referenced?

Yes certainly! I've started working on this already. Thanks for the helpful guidance.

[ajpaverd]

Here are the items requested above:

• Updated documentation for Control Flow Guard #72945 adds documentation about this flag to the unstable book.

• Control Flow Guard for Rust.pdf is a write-up about how CFG is implemented in Rust, benefits and drawbacks of enabling it, and a discussion about CFG in the standard library.

• Control Flow Guard for LLVM.pdf is a detailed explanation of how CFG is implemented in LLVM.

Apologies for the delay on this. Let me know if any further clarification is needed.

[nikomatsakis]

@ajpaverd thanks! For those who are curious, here is a link to the chapter in the unstable book.

Ideally @ajpaverd the implementation documentation would make its way into the rustc-dev-guide, I have to say you went above and beyond the call of duty there, it seems very thorough. =)