Retpoline support in rustc (target features or dedicated flags)
#116852
Labels
A-codegen
Area: Code generation
C-feature-request
Category: A feature request, i.e: not implemented / a PR.
PG-exploit-mitigations
Project group: Exploit mitigations
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
rustbot
added
the
needs-triage
52 tasks
Noratrieb
added
A-codegen
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this issue
Jul 24, 2024
Support `MITIGATION_RETPOLINE` by enabling the target features that
Clang does.
The existing target feature being enabled was a leftover from
our old `rust` branch, and it is not enough: the target feature
`retpoline-external-thunk` only implies `retpoline-indirect-calls`, but
not `retpoline-indirect-branches` (see LLVM's `X86.td`), unlike Clang's
flag of the same name `-mretpoline-external-thunk` which does imply both
(see Clang's `lib/Driver/ToolChains/Arch/X86.cpp`).
Without this, `objtool` would complain if enabled for Rust, e.g.:
rust/core.o: warning: objtool:
_R...escape_default+0x13: indirect jump found in RETPOLINE build
In addition, change the comment to note that LLVM is the one disabling
jump tables when retpoline is enabled, thus we do not need to use
`-Zno-jump-tables` for Rust here -- see commit c58f2166ab39 ("Introduce
the "retpoline" x86 mitigation technique ...") [1]:
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In
many cases, the compiler can simply use directed conditional
branches and a small search tree. LLVM already has support for
lowering switches in this way and the first step of this patch is
to disable jump-table lowering of switches and introduce a pass to
rewrite explicit indirectbr sequences into a switch over integers.
As well as a live example at [2].
These should be eventually enabled via `-Ctarget-feature` when `rustc`
starts recognizing them (or via a new dedicated flag) [3].
Cc: Daniel Borkmann <[email protected]>
Link: llvm/llvm-project@c58f216 [1]
Link: https://godbolt.org/z/G4YPr58qG [2]
Link: rust-lang/rust#116852 [3]
Signed-off-by: Miguel Ojeda <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this issue
Jul 25, 2024
Support `MITIGATION_RETPOLINE` by enabling the target features that
Clang does.
The existing target feature being enabled was a leftover from
our old `rust` branch, and it is not enough: the target feature
`retpoline-external-thunk` only implies `retpoline-indirect-calls`, but
not `retpoline-indirect-branches` (see LLVM's `X86.td`), unlike Clang's
flag of the same name `-mretpoline-external-thunk` which does imply both
(see Clang's `lib/Driver/ToolChains/Arch/X86.cpp`).
Without this, `objtool` would complain if enabled for Rust, e.g.:
rust/core.o: warning: objtool:
_R...escape_default+0x13: indirect jump found in RETPOLINE build
In addition, change the comment to note that LLVM is the one disabling
jump tables when retpoline is enabled, thus we do not need to use
`-Zno-jump-tables` for Rust here -- see commit c58f2166ab39 ("Introduce
the "retpoline" x86 mitigation technique ...") [1]:
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In
many cases, the compiler can simply use directed conditional
branches and a small search tree. LLVM already has support for
lowering switches in this way and the first step of this patch is
to disable jump-table lowering of switches and introduce a pass to
rewrite explicit indirectbr sequences into a switch over integers.
As well as a live example at [2].
These should be eventually enabled via `-Ctarget-feature` when `rustc`
starts recognizing them (or via a new dedicated flag) [3].
Cc: Daniel Borkmann <[email protected]>
Link: llvm/llvm-project@c58f216 [1]
Link: https://godbolt.org/z/G4YPr58qG [2]
Link: rust-lang/rust#116852 [3]
Reviewed-by: Gary Guo <[email protected]>
Tested-by: Alice Ryhl <[email protected]>
Tested-by: Benno Lossin <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>
Darksonn
pushed a commit
to Darksonn/linux
that referenced
this issue
Aug 7, 2024
Support `MITIGATION_RETPOLINE` by enabling the target features that
Clang does.
The existing target feature being enabled was a leftover from
our old `rust` branch, and it is not enough: the target feature
`retpoline-external-thunk` only implies `retpoline-indirect-calls`, but
not `retpoline-indirect-branches` (see LLVM's `X86.td`), unlike Clang's
flag of the same name `-mretpoline-external-thunk` which does imply both
(see Clang's `lib/Driver/ToolChains/Arch/X86.cpp`).
Without this, `objtool` would complain if enabled for Rust, e.g.:
rust/core.o: warning: objtool:
_R...escape_default+0x13: indirect jump found in RETPOLINE build
In addition, change the comment to note that LLVM is the one disabling
jump tables when retpoline is enabled, thus we do not need to use
`-Zno-jump-tables` for Rust here -- see commit c58f2166ab39 ("Introduce
the "retpoline" x86 mitigation technique ...") [1]:
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In
many cases, the compiler can simply use directed conditional
branches and a small search tree. LLVM already has support for
lowering switches in this way and the first step of this patch is
to disable jump-table lowering of switches and introduce a pass to
rewrite explicit indirectbr sequences into a switch over integers.
As well as a live example at [2].
These should be eventually enabled via `-Ctarget-feature` when `rustc`
starts recognizing them (or via a new dedicated flag) [3].
Cc: Daniel Borkmann <[email protected]>
Link: llvm/llvm-project@c58f216 [1]
Link: https://godbolt.org/z/G4YPr58qG [2]
Link: rust-lang/rust#116852 [3]
Reviewed-by: Gary Guo <[email protected]>
Tested-by: Alice Ryhl <[email protected]>
Tested-by: Benno Lossin <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>
Darksonn
pushed a commit
to Darksonn/linux
that referenced
this issue
Aug 7, 2024
Support `MITIGATION_RETPOLINE` by enabling the target features that
Clang does.
The existing target feature being enabled was a leftover from
our old `rust` branch, and it is not enough: the target feature
`retpoline-external-thunk` only implies `retpoline-indirect-calls`, but
not `retpoline-indirect-branches` (see LLVM's `X86.td`), unlike Clang's
flag of the same name `-mretpoline-external-thunk` which does imply both
(see Clang's `lib/Driver/ToolChains/Arch/X86.cpp`).
Without this, `objtool` would complain if enabled for Rust, e.g.:
rust/core.o: warning: objtool:
_R...escape_default+0x13: indirect jump found in RETPOLINE build
In addition, change the comment to note that LLVM is the one disabling
jump tables when retpoline is enabled, thus we do not need to use
`-Zno-jump-tables` for Rust here -- see commit c58f2166ab39 ("Introduce
the "retpoline" x86 mitigation technique ...") [1]:
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In
many cases, the compiler can simply use directed conditional
branches and a small search tree. LLVM already has support for
lowering switches in this way and the first step of this patch is
to disable jump-table lowering of switches and introduce a pass to
rewrite explicit indirectbr sequences into a switch over integers.
As well as a live example at [2].
These should be eventually enabled via `-Ctarget-feature` when `rustc`
starts recognizing them (or via a new dedicated flag) [3].
Cc: Daniel Borkmann <[email protected]>
Link: llvm/llvm-project@c58f216 [1]
Link: https://godbolt.org/z/G4YPr58qG [2]
Link: rust-lang/rust#116852 [3]
Reviewed-by: Gary Guo <[email protected]>
Tested-by: Alice Ryhl <[email protected]>
Tested-by: Benno Lossin <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>
Darksonn
pushed a commit
to Darksonn/linux
that referenced
this issue
Aug 8, 2024
Support `MITIGATION_RETPOLINE` by enabling the target features that
Clang does.
The existing target feature being enabled was a leftover from
our old `rust` branch, and it is not enough: the target feature
`retpoline-external-thunk` only implies `retpoline-indirect-calls`, but
not `retpoline-indirect-branches` (see LLVM's `X86.td`), unlike Clang's
flag of the same name `-mretpoline-external-thunk` which does imply both
(see Clang's `lib/Driver/ToolChains/Arch/X86.cpp`).
Without this, `objtool` would complain if enabled for Rust, e.g.:
rust/core.o: warning: objtool:
_R...escape_default+0x13: indirect jump found in RETPOLINE build
In addition, change the comment to note that LLVM is the one disabling
jump tables when retpoline is enabled, thus we do not need to use
`-Zno-jump-tables` for Rust here -- see commit c58f2166ab39 ("Introduce
the "retpoline" x86 mitigation technique ...") [1]:
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In
many cases, the compiler can simply use directed conditional
branches and a small search tree. LLVM already has support for
lowering switches in this way and the first step of this patch is
to disable jump-table lowering of switches and introduce a pass to
rewrite explicit indirectbr sequences into a switch over integers.
As well as a live example at [2].
These should be eventually enabled via `-Ctarget-feature` when `rustc`
starts recognizing them (or via a new dedicated flag) [3].
Cc: Daniel Borkmann <[email protected]>
Link: llvm/llvm-project@c58f216 [1]
Link: https://godbolt.org/z/G4YPr58qG [2]
Link: rust-lang/rust#116852 [3]
Reviewed-by: Gary Guo <[email protected]>
Tested-by: Alice Ryhl <[email protected]>
Tested-by: Benno Lossin <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>
Darksonn
pushed a commit
to Darksonn/linux
that referenced
this issue
Aug 8, 2024
Support `MITIGATION_RETPOLINE` by enabling the target features that
Clang does.
The existing target feature being enabled was a leftover from
our old `rust` branch, and it is not enough: the target feature
`retpoline-external-thunk` only implies `retpoline-indirect-calls`, but
not `retpoline-indirect-branches` (see LLVM's `X86.td`), unlike Clang's
flag of the same name `-mretpoline-external-thunk` which does imply both
(see Clang's `lib/Driver/ToolChains/Arch/X86.cpp`).
Without this, `objtool` would complain if enabled for Rust, e.g.:
rust/core.o: warning: objtool:
_R...escape_default+0x13: indirect jump found in RETPOLINE build
In addition, change the comment to note that LLVM is the one disabling
jump tables when retpoline is enabled, thus we do not need to use
`-Zno-jump-tables` for Rust here -- see commit c58f2166ab39 ("Introduce
the "retpoline" x86 mitigation technique ...") [1]:
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In
many cases, the compiler can simply use directed conditional
branches and a small search tree. LLVM already has support for
lowering switches in this way and the first step of this patch is
to disable jump-table lowering of switches and introduce a pass to
rewrite explicit indirectbr sequences into a switch over integers.
As well as a live example at [2].
These should be eventually enabled via `-Ctarget-feature` when `rustc`
starts recognizing them (or via a new dedicated flag) [3].
Cc: Daniel Borkmann <[email protected]>
Link: llvm/llvm-project@c58f216 [1]
Link: https://godbolt.org/z/G4YPr58qG [2]
Link: rust-lang/rust#116852 [3]
Reviewed-by: Gary Guo <[email protected]>
Tested-by: Alice Ryhl <[email protected]>
Tested-by: Benno Lossin <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>
samitolvanen
pushed a commit
to samitolvanen/linux
that referenced
this issue
Aug 15, 2024
Support `MITIGATION_RETPOLINE` by enabling the target features that
Clang does.
The existing target feature being enabled was a leftover from
our old `rust` branch, and it is not enough: the target feature
`retpoline-external-thunk` only implies `retpoline-indirect-calls`, but
not `retpoline-indirect-branches` (see LLVM's `X86.td`), unlike Clang's
flag of the same name `-mretpoline-external-thunk` which does imply both
(see Clang's `lib/Driver/ToolChains/Arch/X86.cpp`).
Without this, `objtool` would complain if enabled for Rust, e.g.:
rust/core.o: warning: objtool:
_R...escape_default+0x13: indirect jump found in RETPOLINE build
In addition, change the comment to note that LLVM is the one disabling
jump tables when retpoline is enabled, thus we do not need to use
`-Zno-jump-tables` for Rust here -- see commit c58f2166ab39 ("Introduce
the "retpoline" x86 mitigation technique ...") [1]:
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In
many cases, the compiler can simply use directed conditional
branches and a small search tree. LLVM already has support for
lowering switches in this way and the first step of this patch is
to disable jump-table lowering of switches and introduce a pass to
rewrite explicit indirectbr sequences into a switch over integers.
As well as a live example at [2].
These should be eventually enabled via `-Ctarget-feature` when `rustc`
starts recognizing them (or via a new dedicated flag) [3].
Cc: Daniel Borkmann <[email protected]>
Link: llvm/llvm-project@c58f216 [1]
Link: https://godbolt.org/z/G4YPr58qG [2]
Link: rust-lang/rust#116852 [3]
Reviewed-by: Gary Guo <[email protected]>
Tested-by: Alice Ryhl <[email protected]>
Tested-by: Benno Lossin <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>
samitolvanen
pushed a commit
to samitolvanen/linux
that referenced
this issue
Aug 15, 2024
Support `MITIGATION_RETPOLINE` by enabling the target features that
Clang does.
The existing target feature being enabled was a leftover from
our old `rust` branch, and it is not enough: the target feature
`retpoline-external-thunk` only implies `retpoline-indirect-calls`, but
not `retpoline-indirect-branches` (see LLVM's `X86.td`), unlike Clang's
flag of the same name `-mretpoline-external-thunk` which does imply both
(see Clang's `lib/Driver/ToolChains/Arch/X86.cpp`).
Without this, `objtool` would complain if enabled for Rust, e.g.:
rust/core.o: warning: objtool:
_R...escape_default+0x13: indirect jump found in RETPOLINE build
In addition, change the comment to note that LLVM is the one disabling
jump tables when retpoline is enabled, thus we do not need to use
`-Zno-jump-tables` for Rust here -- see commit c58f2166ab39 ("Introduce
the "retpoline" x86 mitigation technique ...") [1]:
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In
many cases, the compiler can simply use directed conditional
branches and a small search tree. LLVM already has support for
lowering switches in this way and the first step of this patch is
to disable jump-table lowering of switches and introduce a pass to
rewrite explicit indirectbr sequences into a switch over integers.
As well as a live example at [2].
These should be eventually enabled via `-Ctarget-feature` when `rustc`
starts recognizing them (or via a new dedicated flag) [3].
Cc: Daniel Borkmann <[email protected]>
Link: llvm/llvm-project@c58f216 [1]
Link: https://godbolt.org/z/G4YPr58qG [2]
Link: rust-lang/rust#116852 [3]
Reviewed-by: Gary Guo <[email protected]>
Tested-by: Alice Ryhl <[email protected]>
Tested-by: Benno Lossin <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>
samitolvanen
pushed a commit
to samitolvanen/linux
that referenced
this issue
Aug 15, 2024
Support `MITIGATION_RETPOLINE` by enabling the target features that
Clang does.
The existing target feature being enabled was a leftover from
our old `rust` branch, and it is not enough: the target feature
`retpoline-external-thunk` only implies `retpoline-indirect-calls`, but
not `retpoline-indirect-branches` (see LLVM's `X86.td`), unlike Clang's
flag of the same name `-mretpoline-external-thunk` which does imply both
(see Clang's `lib/Driver/ToolChains/Arch/X86.cpp`).
Without this, `objtool` would complain if enabled for Rust, e.g.:
rust/core.o: warning: objtool:
_R...escape_default+0x13: indirect jump found in RETPOLINE build
In addition, change the comment to note that LLVM is the one disabling
jump tables when retpoline is enabled, thus we do not need to use
`-Zno-jump-tables` for Rust here -- see commit c58f2166ab39 ("Introduce
the "retpoline" x86 mitigation technique ...") [1]:
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In
many cases, the compiler can simply use directed conditional
branches and a small search tree. LLVM already has support for
lowering switches in this way and the first step of this patch is
to disable jump-table lowering of switches and introduce a pass to
rewrite explicit indirectbr sequences into a switch over integers.
As well as a live example at [2].
These should be eventually enabled via `-Ctarget-feature` when `rustc`
starts recognizing them (or via a new dedicated flag) [3].
Cc: Daniel Borkmann <[email protected]>
Link: llvm/llvm-project@c58f216 [1]
Link: https://godbolt.org/z/G4YPr58qG [2]
Link: rust-lang/rust#116852 [3]
Reviewed-by: Gary Guo <[email protected]>
Tested-by: Alice Ryhl <[email protected]>
Tested-by: Benno Lossin <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>
hubot
pushed a commit
to aosp-mirror/kernel_common
that referenced
this issue
Aug 16, 2024
Support `MITIGATION_RETPOLINE` by enabling the target features that
Clang does.
The existing target feature being enabled was a leftover from
our old `rust` branch, and it is not enough: the target feature
`retpoline-external-thunk` only implies `retpoline-indirect-calls`, but
not `retpoline-indirect-branches` (see LLVM's `X86.td`), unlike Clang's
flag of the same name `-mretpoline-external-thunk` which does imply both
(see Clang's `lib/Driver/ToolChains/Arch/X86.cpp`).
Without this, `objtool` would complain if enabled for Rust, e.g.:
rust/core.o: warning: objtool:
_R...escape_default+0x13: indirect jump found in RETPOLINE build
In addition, change the comment to note that LLVM is the one disabling
jump tables when retpoline is enabled, thus we do not need to use
`-Zno-jump-tables` for Rust here -- see commit c58f2166ab39 ("Introduce
the "retpoline" x86 mitigation technique ...") [1]:
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In
many cases, the compiler can simply use directed conditional
branches and a small search tree. LLVM already has support for
lowering switches in this way and the first step of this patch is
to disable jump-table lowering of switches and introduce a pass to
rewrite explicit indirectbr sequences into a switch over integers.
As well as a live example at [2].
These should be eventually enabled via `-Ctarget-feature` when `rustc`
starts recognizing them (or via a new dedicated flag) [3].
Cc: Daniel Borkmann <[email protected]>
Link: llvm/llvm-project@c58f216 [1]
Link: https://godbolt.org/z/G4YPr58qG [2]
Link: rust-lang/rust#116852 [3]
Reviewed-by: Gary Guo <[email protected]>
Tested-by: Alice Ryhl <[email protected]>
Tested-by: Benno Lossin <[email protected]>
Change-Id: Ieb8b1bf77e95000211d98e5a6ca618ea120ce3b2
Signed-off-by: Miguel Ojeda <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alice Ryhl <[email protected]>
Darksonn
pushed a commit
to Darksonn/linux
that referenced
this issue
Aug 16, 2024
Support `MITIGATION_RETPOLINE` by enabling the target features that
Clang does.
The existing target feature being enabled was a leftover from
our old `rust` branch, and it is not enough: the target feature
`retpoline-external-thunk` only implies `retpoline-indirect-calls`, but
not `retpoline-indirect-branches` (see LLVM's `X86.td`), unlike Clang's
flag of the same name `-mretpoline-external-thunk` which does imply both
(see Clang's `lib/Driver/ToolChains/Arch/X86.cpp`).
Without this, `objtool` would complain if enabled for Rust, e.g.:
rust/core.o: warning: objtool:
_R...escape_default+0x13: indirect jump found in RETPOLINE build
In addition, change the comment to note that LLVM is the one disabling
jump tables when retpoline is enabled, thus we do not need to use
`-Zno-jump-tables` for Rust here -- see commit c58f2166ab39 ("Introduce
the "retpoline" x86 mitigation technique ...") [1]:
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In
many cases, the compiler can simply use directed conditional
branches and a small search tree. LLVM already has support for
lowering switches in this way and the first step of this patch is
to disable jump-table lowering of switches and introduce a pass to
rewrite explicit indirectbr sequences into a switch over integers.
As well as a live example at [2].
These should be eventually enabled via `-Ctarget-feature` when `rustc`
starts recognizing them (or via a new dedicated flag) [3].
Cc: Daniel Borkmann <[email protected]>
Link: llvm/llvm-project@c58f216 [1]
Link: https://godbolt.org/z/G4YPr58qG [2]
Link: rust-lang/rust#116852 [3]
Reviewed-by: Gary Guo <[email protected]>
Tested-by: Alice Ryhl <[email protected]>
Tested-by: Benno Lossin <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>
ojeda
added a commit
to ojeda/linux
that referenced
this issue
Aug 17, 2024
Support `MITIGATION_RETPOLINE` by enabling the target features that
Clang does.
The existing target feature being enabled was a leftover from
our old `rust` branch, and it is not enough: the target feature
`retpoline-external-thunk` only implies `retpoline-indirect-calls`, but
not `retpoline-indirect-branches` (see LLVM's `X86.td`), unlike Clang's
flag of the same name `-mretpoline-external-thunk` which does imply both
(see Clang's `lib/Driver/ToolChains/Arch/X86.cpp`).
Without this, `objtool` would complain if enabled for Rust, e.g.:
rust/core.o: warning: objtool:
_R...escape_default+0x13: indirect jump found in RETPOLINE build
In addition, change the comment to note that LLVM is the one disabling
jump tables when retpoline is enabled, thus we do not need to use
`-Zno-jump-tables` for Rust here -- see commit c58f2166ab39 ("Introduce
the "retpoline" x86 mitigation technique ...") [1]:
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In
many cases, the compiler can simply use directed conditional
branches and a small search tree. LLVM already has support for
lowering switches in this way and the first step of this patch is
to disable jump-table lowering of switches and introduce a pass to
rewrite explicit indirectbr sequences into a switch over integers.
As well as a live example at [2].
These should be eventually enabled via `-Ctarget-feature` when `rustc`
starts recognizing them (or via a new dedicated flag) [3].
Cc: Daniel Borkmann <[email protected]>
Link: llvm/llvm-project@c58f216 [1]
Link: https://godbolt.org/z/G4YPr58qG [2]
Link: rust-lang/rust#116852 [3]
Reviewed-by: Gary Guo <[email protected]>
Tested-by: Alice Ryhl <[email protected]>
Tested-by: Benno Lossin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
ojeda
added a commit
to ojeda/linux
that referenced
this issue
Aug 17, 2024
Support `MITIGATION_RETPOLINE` by enabling the target features that
Clang does.
The existing target feature being enabled was a leftover from
our old `rust` branch, and it is not enough: the target feature
`retpoline-external-thunk` only implies `retpoline-indirect-calls`, but
not `retpoline-indirect-branches` (see LLVM's `X86.td`), unlike Clang's
flag of the same name `-mretpoline-external-thunk` which does imply both
(see Clang's `lib/Driver/ToolChains/Arch/X86.cpp`).
Without this, `objtool` would complain if enabled for Rust, e.g.:
rust/core.o: warning: objtool:
_R...escape_default+0x13: indirect jump found in RETPOLINE build
In addition, change the comment to note that LLVM is the one disabling
jump tables when retpoline is enabled, thus we do not need to use
`-Zno-jump-tables` for Rust here -- see commit c58f2166ab39 ("Introduce
the "retpoline" x86 mitigation technique ...") [1]:
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In
many cases, the compiler can simply use directed conditional
branches and a small search tree. LLVM already has support for
lowering switches in this way and the first step of this patch is
to disable jump-table lowering of switches and introduce a pass to
rewrite explicit indirectbr sequences into a switch over integers.
As well as a live example at [2].
These should be eventually enabled via `-Ctarget-feature` when `rustc`
starts recognizing them (or via a new dedicated flag) [3].
Cc: Daniel Borkmann <[email protected]>
Link: llvm/llvm-project@c58f216 [1]
Link: https://godbolt.org/z/G4YPr58qG [2]
Link: rust-lang/rust#116852 [3]
Reviewed-by: Gary Guo <[email protected]>
Tested-by: Alice Ryhl <[email protected]>
Tested-by: Benno Lossin <[email protected]>
Link: Rust-for-Linux#945
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
ojeda
added a commit
to Rust-for-Linux/linux
that referenced
this issue
Aug 18, 2024
Support `MITIGATION_RETPOLINE` by enabling the target features that
Clang does.
The existing target feature being enabled was a leftover from
our old `rust` branch, and it is not enough: the target feature
`retpoline-external-thunk` only implies `retpoline-indirect-calls`, but
not `retpoline-indirect-branches` (see LLVM's `X86.td`), unlike Clang's
flag of the same name `-mretpoline-external-thunk` which does imply both
(see Clang's `lib/Driver/ToolChains/Arch/X86.cpp`).
Without this, `objtool` would complain if enabled for Rust, e.g.:
rust/core.o: warning: objtool:
_R...escape_default+0x13: indirect jump found in RETPOLINE build
In addition, change the comment to note that LLVM is the one disabling
jump tables when retpoline is enabled, thus we do not need to use
`-Zno-jump-tables` for Rust here -- see commit c58f2166ab39 ("Introduce
the "retpoline" x86 mitigation technique ...") [1]:
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In
many cases, the compiler can simply use directed conditional
branches and a small search tree. LLVM already has support for
lowering switches in this way and the first step of this patch is
to disable jump-table lowering of switches and introduce a pass to
rewrite explicit indirectbr sequences into a switch over integers.
As well as a live example at [2].
These should be eventually enabled via `-Ctarget-feature` when `rustc`
starts recognizing them (or via a new dedicated flag) [3].
Cc: Daniel Borkmann <[email protected]>
Link: llvm/llvm-project@c58f216 [1]
Link: https://godbolt.org/z/G4YPr58qG [2]
Link: rust-lang/rust#116852 [3]
Reviewed-by: Gary Guo <[email protected]>
Tested-by: Alice Ryhl <[email protected]>
Tested-by: Benno Lossin <[email protected]>
Link: #945
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
ojeda
added a commit
to Rust-for-Linux/linux
that referenced
this issue
Aug 18, 2024
Support `MITIGATION_RETPOLINE` by enabling the target features that
Clang does.
The existing target feature being enabled was a leftover from
our old `rust` branch, and it is not enough: the target feature
`retpoline-external-thunk` only implies `retpoline-indirect-calls`, but
not `retpoline-indirect-branches` (see LLVM's `X86.td`), unlike Clang's
flag of the same name `-mretpoline-external-thunk` which does imply both
(see Clang's `lib/Driver/ToolChains/Arch/X86.cpp`).
Without this, `objtool` would complain if enabled for Rust, e.g.:
rust/core.o: warning: objtool:
_R...escape_default+0x13: indirect jump found in RETPOLINE build
In addition, change the comment to note that LLVM is the one disabling
jump tables when retpoline is enabled, thus we do not need to use
`-Zno-jump-tables` for Rust here -- see commit c58f2166ab39 ("Introduce
the "retpoline" x86 mitigation technique ...") [1]:
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In
many cases, the compiler can simply use directed conditional
branches and a small search tree. LLVM already has support for
lowering switches in this way and the first step of this patch is
to disable jump-table lowering of switches and introduce a pass to
rewrite explicit indirectbr sequences into a switch over integers.
As well as a live example at [2].
These should be eventually enabled via `-Ctarget-feature` when `rustc`
starts recognizing them (or via a new dedicated flag) [3].
Cc: Daniel Borkmann <[email protected]>
Link: llvm/llvm-project@c58f216 [1]
Link: https://godbolt.org/z/G4YPr58qG [2]
Link: rust-lang/rust#116852 [3]
Reviewed-by: Gary Guo <[email protected]>
Tested-by: Alice Ryhl <[email protected]>
Tested-by: Benno Lossin <[email protected]>
Link: #945
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
Darksonn
pushed a commit
to Darksonn/linux
that referenced
this issue
Aug 22, 2024
Support `MITIGATION_RETPOLINE` by enabling the target features that
Clang does.
The existing target feature being enabled was a leftover from
our old `rust` branch, and it is not enough: the target feature
`retpoline-external-thunk` only implies `retpoline-indirect-calls`, but
not `retpoline-indirect-branches` (see LLVM's `X86.td`), unlike Clang's
flag of the same name `-mretpoline-external-thunk` which does imply both
(see Clang's `lib/Driver/ToolChains/Arch/X86.cpp`).
Without this, `objtool` would complain if enabled for Rust, e.g.:
rust/core.o: warning: objtool:
_R...escape_default+0x13: indirect jump found in RETPOLINE build
In addition, change the comment to note that LLVM is the one disabling
jump tables when retpoline is enabled, thus we do not need to use
`-Zno-jump-tables` for Rust here -- see commit c58f2166ab39 ("Introduce
the "retpoline" x86 mitigation technique ...") [1]:
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In
many cases, the compiler can simply use directed conditional
branches and a small search tree. LLVM already has support for
lowering switches in this way and the first step of this patch is
to disable jump-table lowering of switches and introduce a pass to
rewrite explicit indirectbr sequences into a switch over integers.
As well as a live example at [2].
These should be eventually enabled via `-Ctarget-feature` when `rustc`
starts recognizing them (or via a new dedicated flag) [3].
Cc: Daniel Borkmann <[email protected]>
Link: llvm/llvm-project@c58f216 [1]
Link: https://godbolt.org/z/G4YPr58qG [2]
Link: rust-lang/rust#116852 [3]
Reviewed-by: Gary Guo <[email protected]>
Tested-by: Alice Ryhl <[email protected]>
Tested-by: Benno Lossin <[email protected]>
Link: Rust-for-Linux#945
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
|
If I understand @Darksonn correctly in this discussion, then these target features affect ABI and therefore they should not be added to the known feature list. Actually they should be added to the "forbidden features" list that will hopefully be introduced soon (#129884), because ABI differences make it unsound to combine code built with and without these target features. |
|
We still need a stable way to disable/enable them (globally). We can use the target specification for the moment, but that is unstable ("Target specification file or enough command-line flags to replace it." in Rust-for-Linux/linux#2). |
|
Yeah there is clearly a need for "ABI incompatible target variants". Also see <rust-embedded/wg#792>.
|
Note that soundly adding something like "ABI vairants" requires |
|
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently:
seems to work as expected, but the features are unknown, and so since 1.61 they emit a warning:
Could/should these be added as known features to avoid using the target specification file?
In an old issue at #54637 it seems that back then dedicated flags were not intended (like Clang's
-mretpoline-external-thunkand GCC's-mindirect-branch=thunk-extern -mindirect-branch-register), which perhaps make a bit more sense.The text was updated successfully, but these errors were encountered: