Add -Z stack-protector-guard

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: https://github.com/rust-lang/rust/pull/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.

Begin by comparing rustc's existing -Z branch-protection implementation with the LLVM stack-protector guard metadata listed in the proposal. Check how the proposed target modifier should parse its mode, offset, register, and symbol options, then verify the stated architecture restrictions and crate-graph consistency. Done means the proposal's guard modes and validations are exposed consistently, with coverage for the supported targets.