retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features #135927

azhogin · 2025-01-23T10:46:14Z

-Zretpoline and -Zretpoline-external-thunk flags are target modifiers (tracked to be equal in linked crates).

Enables target features for -Zretpoline-external-thunk:
+retpoline-external-thunk, +retpoline-indirect-branches, +retpoline-indirect-calls.
Enables target features for -Zretpoline:
+retpoline-indirect-branches, +retpoline-indirect-calls.

It corresponds to clang -mretpoline & -mretpoline-external-thunk flags.

Also this PR forbids to specify those target features manually (warning).

rustbot · 2025-01-23T10:46:22Z

rustbot has assigned @compiler-errors.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

rustbot · 2025-01-23T10:46:25Z

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

compiler-errors · 2025-01-23T18:12:36Z

r? compiler

bors · 2025-01-26T10:22:32Z

☔ The latest upstream changes (presumably #136085) made this pull request unmergeable. Please resolve the merge conflicts.

chenyukang · 2025-02-05T02:30:16Z

r? compiler

fee1-dead · 2025-02-08T01:29:07Z

r? compiler

lcnr · 2025-02-09T18:12:07Z

r? @davidtwco maybe 😅

Darksonn · 2025-02-13T08:57:50Z

I don't think retpoline actually changes the ABI, so it might not need to be a target modifier. On the other hand, as an exploit mitigation, we do still want to avoid cases where you don't enable the mitigation in every compilation unit.

cc @andyhhp do I understand things correctly?

azhogin · 2025-02-13T09:34:27Z

I don't think retpoline actually changes the ABI, so it might not need to be a target modifier. On the other hand, as an exploit mitigation, we do still want to avoid cases where you don't enable the mitigation in every compilation unit.

I read your post in #116852:

I've investigated this issue in more details. It turns out that the retpoline mitigations do not affect ABI and can be mixed.

Mixing them gives up their advantage, though. Linking together two compilation units that disagree on whether to apply the mitigation may make both vulnerable to what they attempt to mitigate.

That's why I thought it should be a target modifier.

andyhhp · 2025-02-14T01:55:46Z

I don't think retpoline actually changes the ABI, so it might not need to be a target modifier. On the other hand, as an exploit mitigation, we do still want to avoid cases where you don't enable the mitigation in every compilation unit.

cc @andyhhp do I understand things correctly?

It's important to distinguish the general indirect-thunk transform from retpoline which is one specific transform (and is not effective on any Intel CPUs since Skylake).

retpoline is the specifically transform of an indirect call/jmp instruction into a call; int3; rewrite-ra; ret ROP gadget with the same net effect, but causes prediction to come from the RSB rather than the BTB.

The need to rewrite the return address on the stack necessitates the use of a GPR, and this is observable call/jmp-ee but any non-parameter register will do, so it doesn't impact the main function call ABI.

Even within retpoline itself, there are variations; inline retpolines are an option, but tend to be heavy on the code bloat side, which is why out-of-line retpolines in common sections are often preferred.

The alternatives to repoline are lfence;jmp (used on some Atom processors where retpoline isn't safe. Previously recommended by AMD but later rescinded), and re-inlining the original indirect branch (when hardware is believed safe, which is a contentious point because it can be made safe on AMD, but only "pretty safe" Intel.)

As to separate complication units, you can mix and match, but if any one piece of your whole process isn't taking safety precautions, then you've lost.

azhogin · 2025-02-25T18:31:52Z

It's important to distinguish the general indirect-thunk transform from retpoline which is one specific transform (and is not effective on any Intel CPUs since Skylake).

Could you, please, recommend the right way to represent this flag according with +retpoline-external-thunk, +retpoline-indirect-branches, +retpoline-indirect-calls target features?

Should it be -Zx86-retpoline=[fixed_variant_of_features1|fixed_variant_of_features2|...] as in harden-sls (#136597)?
Or simple features list like -Zx86-retpoline=external-thunk,indirect-calls?

Darksonn · 2025-03-13T11:59:27Z

I would think that the best choice would be to use the same name as clang, which is -mretpoline-external-thunk. So that would be -Zretpoline-external-thunk.

ojeda · 2025-03-13T12:13:00Z

Yeah, personally, I prefer when compiler drivers agree. rustc tends to diverge a fair amount, but at least if "uncommon" flags have the same names it would help a bit.

…o enable retpoline-related target features

azhogin · 2025-03-25T15:38:59Z

-Zretpoline-external-thunk flag enables:
+retpoline-external-thunk, +retpoline-indirect-branches, +retpoline-indirect-calls.
-Zretpoline flag enables:
+retpoline-indirect-branches, +retpoline-indirect-calls

-Zretpoline-external-thunk also turns on -Zretpoline.

Looks like it corresponds to clang flags.

rustbot · 2025-03-26T06:48:43Z

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

WaffleLapkin · 2025-04-09T16:16:21Z

compiler/rustc_target/src/target_features.rs

        }
    }

    /// Returns whether the feature may be toggled via `#[target_feature]` or `-Ctarget-feature`.
    /// (It might still be nightly-only even if this returns `true`, so make sure to also check
    /// `requires_nightly`.)
-    pub fn toggle_allowed(&self) -> Result<(), &'static str> {


this API seems confusing, at the very least change the doc comment.

davidtwco

Per the team documentation, adding a new flag with the intent to later stabilise requires an MCP - https://forge.rust-lang.org/compiler/proposals-and-stabilization.html#compiler-flags

davidtwco · 2025-04-16T12:42:07Z

compiler/rustc_target/src/target_features.rs

        }
    }

    /// Returns whether the feature may be toggled via `#[target_feature]` or `-Ctarget-feature`.
    /// (It might still be nightly-only even if this returns `true`, so make sure to also check
    /// `requires_nightly`.)
-    pub fn toggle_allowed(&self) -> Result<(), &'static str> {
+    pub fn toggle_allowed(&self, flag_enabled: impl Fn(&str) -> bool) -> Result<(), &'static str> {


pre-existing: this name is a little ambiguous, is it toggling something named allowed, or is toggling allowed? maybe is_toggle_permitted instead or just is_toggle_allowed?

davidtwco · 2025-04-16T12:55:17Z

compiler/rustc_codegen_llvm/src/llvm_util.rs

@@ -733,7 +733,9 @@ pub(crate) fn global_llvm_features(
                        sess.dcx().emit_warn(unknown_feature);
                    }
                    Some((_, stability, _)) => {
-                        if let Err(reason) = stability.toggle_allowed() {


There's a bunch of duplication in the code around this between codegen backends and rustc_codegen_ssa, it's pre-existing, you could sort it if you wanted, but someone ought to.

davidtwco · 2025-04-16T12:59:32Z

compiler/rustc_session/src/options.rs

+                }
+            }
+
+            pub fn fill_target_features_by_flags(


This doesn't feel like the right place to do this, ideally there would be a query or something that we could add this logic to that would mean that codegen backends just get the features they need to enable and we'd insert this logic into that.

davidtwco · 2025-04-16T13:00:38Z

compiler/rustc_target/src/target_features.rs

        }
    }

    /// Returns whether the feature may be toggled via `#[target_feature]` or `-Ctarget-feature`.
    /// (It might still be nightly-only even if this returns `true`, so make sure to also check
    /// `requires_nightly`.)
-    pub fn toggle_allowed(&self) -> Result<(), &'static str> {
+    pub fn toggle_allowed(&self, flag_enabled: impl Fn(&str) -> bool) -> Result<(), &'static str> {


Could we add a StabilityExt trait in another crate that just takes a Session and calls this with the appropriate closure, given its the same closure everywhere?

davidtwco · 2025-04-16T13:01:15Z

compiler/rustc_target/src/target_features.rs

@@ -34,6 +34,9 @@ pub enum Stability {
    /// particular for features are actually ABI configuration flags (not all targets are as nice as
    /// RISC-V and have an explicit way to set the ABI separate from target features).
    Forbidden { reason: &'static str },
+    /// This feature can not be set via `-Ctarget-feature` or `#[target_feature]`, it can only be set
+    /// by target modifier flag. Target modifier flags are tracked to be consistent in linked modules.
+    EnabledByTargetModifierFlag { reason: &'static str, flag: &'static str },


Suggested change

EnabledByTargetModifierFlag { reason: &'static str, flag: &'static str },

TargetModifierOnly { reason: &'static str, flag: &'static str },

Darksonn · 2025-04-16T13:19:18Z

@rustbot label F-target_modifiers A-rust-for-linux

Darksonn · 2025-04-28T12:01:41Z

I filed an MCP: rust-lang/compiler-team#868

rustbot assigned compiler-errors Jan 23, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Jan 23, 2025

azhogin force-pushed the azhogin/retpoline branch from e808e83 to 12b286f Compare January 23, 2025 10:48