Add -Z stack-protector-guard

[alvinsun039]

Proposal

This MCP proposes adding a new unstable -Z stack-protector-guard target
modifier to configure how the stack canary is accessed, equivalent to
Clang's -mstack-protector-guard=* options.

Rust nightly already supports stack smashing protection via
-Z stack-protector. However, rustc currently always generates code that
reads the canary from the global __stack_chk_guard symbol. This is
incompatible with Linux kernel configurations that enable
CONFIG_STACKPROTECTOR_PER_TASK, where the canary is stored in a
per-task location (e.g. a system register on AArch64, or TLS on x86)
rather than a global variable.

LLVM already supports customizing the guard location via module-level
metadata (stack-protector-guard, stack-protector-guard-offset,
stack-protector-guard-reg, stack-protector-guard-symbol). Clang
exposes this through -mstack-protector-guard=* flags. This MCP proposes
exposing the same functionality in rustc.

The proposed flag uses a comma-separated syntax:

-Z stack-protector-guard=,offset=N,reg=R

• mode: global, tls, or sysreg
• offset=N: offset from the guard base
• reg=R: TLS/system register (e.g. fs, gs, sp_el0)
• symbol=S: custom guard symbol name

Architecture validation:

• x86/x86_64: tls, global
• AArch64: sysreg, global
• ARM: tls, global
• RISC-V 32/64: sysreg, global
• Other architectures: error

This is a target modifier, ensuring consistency across the crate graph

• without it, mismatches would only be caught during LTO.

The implementation follows the same pattern as -Z branch-protection.

Prototype PR: rust-lang/rust#159165

Mentors or Reviewers

@rcvalle

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

[rustbot]

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that.
Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections can formally be registered here by adding a comment.

@rustbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler