rustc-1.73.0 used by Linux does not support entry padding. Mark entry
padding support as explicitly incompatible with Rust.
Signed-off-by: Matthew Maurer <[email protected]>
---
This is temporary - upstream in the Rust compiler, I have:
* A MCP[1] to enable the feature as an unstable flag
* A RFC[2] to stabilize it and add the attribute
* An initial implementation[3] for the MCP and RFC once accepted
Once at least unstable support is merged, we can detect this in a future
patch.
Even once those are merged and Linux is using a newer rustc, we will
still want a separate HAVE_ENTRY_PADDING config, as Rust's gcc backend
will not initially support it.
While this is a temporary patch, I still think it's worth carrying
because it prevents us from selecting build configurations that will
fail at runtime.
[1]: https://github.com/rust-lang/compiler-team/issues/704
[2]: https://github.com/rust-lang/rfcs/pull/3543
[3]: https://github.com/maurer/rust/tree/patchable-function-entries
arch/x86/Kconfig | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 18b9fb7df95b..a9d48709f7db 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2452,6 +2452,9 @@ config CC_HAS_RETURN_THUNK
config CC_HAS_ENTRY_PADDING
def_bool $(cc-option,-fpatchable-function-entry=16,16)
+config HAVE_ENTRY_PADDING
+ def_bool CC_HAS_ENTRY_PADDING && !RUST
+
config FUNCTION_PADDING_CFI
int
default 59 if FUNCTION_ALIGNMENT_64B
@@ -2469,17 +2472,17 @@ config FUNCTION_PADDING_BYTES
config CALL_PADDING
def_bool n
- depends on CC_HAS_ENTRY_PADDING && OBJTOOL
+ depends on HAVE_ENTRY_PADDING && OBJTOOL
select FUNCTION_ALIGNMENT_16B
config FINEIBT
def_bool y
- depends on X86_KERNEL_IBT && CFI_CLANG && RETPOLINE
+ depends on X86_KERNEL_IBT && CFI_CLANG && RETPOLINE && HAVE_ENTRY_PADDING
select CALL_PADDING
config HAVE_CALL_THUNKS
def_bool y
- depends on CC_HAS_ENTRY_PADDING && RETHUNK && OBJTOOL
+ depends on HAVE_ENTRY_PADDING && RETHUNK && OBJTOOL
config CALL_THUNKS
def_bool n
--
2.43.0.472.g3155946c3a-goog
On 12/15/23 16:39, Matthew Maurer wrote:
> rustc-1.73.0 used by Linux does not support entry padding. Mark entry
> padding support as explicitly incompatible with Rust.
>
> Signed-off-by: Matthew Maurer <[email protected]>
> ---
> [...]
Hope your changes to `rustc` land.
Reviewed-by: Martin Rodriguez Reboredo <[email protected]>
On Fri, Dec 15, 2023 at 8:48 PM Matthew Maurer <[email protected]> wrote:
>
> rustc-1.73.0 used by Linux does not support entry padding. Mark entry
> padding support as explicitly incompatible with Rust.
>
> Signed-off-by: Matthew Maurer <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
On Fri, Dec 15, 2023 at 8:48 PM Matthew Maurer <[email protected]> wrote:
>
> rustc-1.73.0 used by Linux does not support entry padding. Mark entry
> padding support as explicitly incompatible with Rust.
We are now at 1.74.1 and moving to 1.75.0 for the next cycle, which
does not support it yet, in case whoever applies the patch wants to
update it in the description.
> Signed-off-by: Matthew Maurer <[email protected]>
x86: are you picking this one up through your tree? Thanks!
Cheers,
Miguel
On 1/28/24 09:48, Miguel Ojeda wrote:
> On Fri, Dec 15, 2023 at 8:48 PM Matthew Maurer <[email protected]> wrote:
>> rustc-1.73.0 used by Linux does not support entry padding. Mark entry
>> padding support as explicitly incompatible with Rust.
> We are now at 1.74.1 and moving to 1.75.0 for the next cycle, which
> does not support it yet, in case whoever applies the patch wants to
> update it in the description.
>
>> Signed-off-by: Matthew Maurer <[email protected]>
> x86: are you picking this one up through your tree? Thanks!
Do we need a 'rust-option' equivalent of 'cc-option', like:
config CC_HAS_ENTRY_PADDING
def_bool $(cc-option,-fpatchable-function-entry=16,16)
That way this doesn't become a temporary option at all. We just do:
config RUST_HAS_ENTRY_PADDING
def_bool $(rust-option,-fpatchable-function-entry) # or whatever
and:
config HAVE_ENTRY_PADDING
def_bool CC_HAS_ENTRY_PADDING
depends on !RUST || RUST_HAS_ENTRY_PADDING
and never have to touch this again.
On Wed, Jan 31, 2024 at 12:46 AM Dave Hansen <[email protected]> wrote:
>
> Do we need a 'rust-option' equivalent of 'cc-option', like:
No, at least until we start supporting several versions of the Rust
compiler (and the current version will not be in that set, so there is
no need to add complexity and spawning extra processes during the
build).
Cheers,
Miguel
On Tue, Jan 30, 2024 at 3:46 PM Dave Hansen <[email protected]> wrote:
>
> On 1/28/24 09:48, Miguel Ojeda wrote:
> > On Fri, Dec 15, 2023 at 8:48 PM Matthew Maurer <[email protected]> wrote:
> >> rustc-1.73.0 used by Linux does not support entry padding. Mark entry
> >> padding support as explicitly incompatible with Rust.
> > We are now at 1.74.1 and moving to 1.75.0 for the next cycle, which
> > does not support it yet, in case whoever applies the patch wants to
> > update it in the description.
> >
> >> Signed-off-by: Matthew Maurer <[email protected]>
> > x86: are you picking this one up through your tree? Thanks!
>
> Do we need a 'rust-option' equivalent of 'cc-option', like:
>
> config CC_HAS_ENTRY_PADDING
> def_bool $(cc-option,-fpatchable-function-entry=16,16)
>
> That way this doesn't become a temporary option at all. We just do:
>
> config RUST_HAS_ENTRY_PADDING
> def_bool $(rust-option,-fpatchable-function-entry) # or whatever
>
> and:
>
> config HAVE_ENTRY_PADDING
> def_bool CC_HAS_ENTRY_PADDING
> depends on !RUST || RUST_HAS_ENTRY_PADDING
>
> and never have to touch this again.
I agree that we'll want something like that in the long term (my
original version of this patch did use something like `rs-option`),
but in this particular case the main thing still being bikeshedded in
the RFC[1] *is* how the option will be specified to the Rust compiler.
We could assume the current form of the RFC which is nearly signed off
on is what will happen, in which case we could add `rs-option` and
test for `-C patchable-function-entry=total_nops=16,prefix_nops=16`,
but there's a chance we could still have to update it until the flag
form is finalized.
Link: https://github.com/rust-lang/rfcs/pull/3543 [1]
On 12/15/23 11:39, Matthew Maurer wrote:
> +config HAVE_ENTRY_PADDING
> + def_bool CC_HAS_ENTRY_PADDING && !RUST
My only worry with this is that we need HAVE_ENTRY_PADDING for:
> config HAVE_CALL_THUNKS
> def_bool y
> depends on CC_HAS_ENTRY_PADDING && RETHUNK && OBJTOOL
..
> config CALL_DEPTH_TRACKING
> bool "Mitigate RSB underflow with call depth tracking"
> depends on CPU_SUP_INTEL && HAVE_CALL_THUNKS
so if they turn on RUST, they'll end up turning off CALL_DEPTH_TRACKING.
I'm wondering if it might be better to do this instead (temporarily of
course):
config RUST
bool "Rust support"
depends on HAVE_RUST
depends on RUST_IS_AVAILABLE
depends on !MODVERSIONS
depends on !GCC_PLUGINS
depends on !RANDSTRUCT
depends on !DEBUG_INFO_BTF || PAHOLE_HAS_LANG_EXCLUDE
+ depends on !CALL_THUNKS
That way, someone who is using CALL_DEPTH_TRACKING doesn't accidentally
lose it by turning on RUST. To turn on RUST, they'd first need to go
turn off the things that are selecting CALL_THUNKS.
On Wed, Jan 31, 2024 at 9:32 PM Dave Hansen <[email protected]> wrote:
>
> That way, someone who is using CALL_DEPTH_TRACKING doesn't accidentally
> lose it by turning on RUST. To turn on RUST, they'd first need to go
> turn off the things that are selecting CALL_THUNKS.
+1, we should prefer to avoid disabling other things, especially since
Rust is still a bit of an "expert" option, so please feel free to add
it to the `RUST` list.
Cheers,
Miguel