[PATCH] x86: rust: Disable entry padding with Rust

[PATCH] x86: rust: Disable entry padding with Rust

[Matthew Maurer]

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 <mmaurer@google.com>
---

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

Re: [PATCH] x86: rust: Disable entry padding with Rust

[Martin Rodriguez Reboredo]

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 <mmaurer@google.com>
> ---
> [...]
Hope your changes to `rustc` land.

Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>

Re: [PATCH] x86: rust: Disable entry padding with Rust

[Alice Ryhl]

On Fri, Dec 15, 2023 at 8:48 PM Matthew Maurer <mmaurer@google.com> 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 <mmaurer@google.com>

Reviewed-by: Alice Ryhl <aliceryhl@google.com>

Re: [PATCH] x86: rust: Disable entry padding with Rust

[Miguel Ojeda]

On Fri, Dec 15, 2023 at 8:48 PM Matthew Maurer <mmaurer@google.com> 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 <mmaurer@google.com>

x86: are you picking this one up through your tree? Thanks!

Cheers,
Miguel

Re: [PATCH] x86: rust: Disable entry padding with Rust

[Dave Hansen]

On 1/28/24 09:48, Miguel Ojeda wrote:
> On Fri, Dec 15, 2023 at 8:48 PM Matthew Maurer <mmaurer@google.com> 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 <mmaurer@google.com>
> 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.

Re: [PATCH] x86: rust: Disable entry padding with Rust

[Miguel Ojeda]

On Wed, Jan 31, 2024 at 12:46 AM Dave Hansen <dave.hansen@intel.com> 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

Re: [PATCH] x86: rust: Disable entry padding with Rust

[Matthew Maurer]

On Tue, Jan 30, 2024 at 3:46 PM Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 1/28/24 09:48, Miguel Ojeda wrote:
> > On Fri, Dec 15, 2023 at 8:48 PM Matthew Maurer <mmaurer@google.com> 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 <mmaurer@google.com>
> > 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]

Re: [PATCH] x86: rust: Disable entry padding with Rust

[Dave Hansen]

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.

Re: [PATCH] x86: rust: Disable entry padding with Rust

[Miguel Ojeda]

On Wed, Jan 31, 2024 at 9:32 PM Dave Hansen <dave.hansen@intel.com> 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