Hi all,
Today's linux-next merge of the rust tree got a conflict in:
arch/x86/Makefile
between commit:
f43b9876e857 ("x86/retbleed: Add fine grained Kconfig knobs")
from Linus' tree and commit:
0ea4b9a1bece ("Kbuild: add Rust support")
from the rust tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/x86/Makefile
index 1f40dad30d50,5ac9b324751d..000000000000
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@@ -21,12 -21,8 +21,13 @@@ ifdef CONFIG_CC_IS_CLAN
RETPOLINE_CFLAGS := -mretpoline-external-thunk
RETPOLINE_VDSO_CFLAGS := -mretpoline
endif
+ RETPOLINE_RUSTFLAGS := -Ctarget-feature=+retpoline-external-thunk
+ifdef CONFIG_RETHUNK
+RETHUNK_CFLAGS := -mfunction-return=thunk-extern
+RETPOLINE_CFLAGS += $(RETHUNK_CFLAGS)
+endif
+
export RETPOLINE_CFLAGS
export RETPOLINE_VDSO_CFLAGS
Hi Stephen,
On Wed, Jul 13, 2022 at 12:34 PM Stephen Rothwell <[email protected]> wrote:
>
> Today's linux-next merge of the rust tree got a conflict in:
>
> arch/x86/Makefile
Thank you, looks good to me.
Cheers,
Miguel
On Wed, Jul 13, 2022 at 08:34:09PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the rust tree got a conflict in:
>
> arch/x86/Makefile
>
> between commit:
>
> f43b9876e857 ("x86/retbleed: Add fine grained Kconfig knobs")
>
> from Linus' tree and commit:
>
> 0ea4b9a1bece ("Kbuild: add Rust support")
>
> from the rust tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/x86/Makefile
> index 1f40dad30d50,5ac9b324751d..000000000000
> --- a/arch/x86/Makefile
> +++ b/arch/x86/Makefile
> @@@ -21,12 -21,8 +21,13 @@@ ifdef CONFIG_CC_IS_CLAN
> RETPOLINE_CFLAGS := -mretpoline-external-thunk
> RETPOLINE_VDSO_CFLAGS := -mretpoline
> endif
> + RETPOLINE_RUSTFLAGS := -Ctarget-feature=+retpoline-external-thunk
>
> +ifdef CONFIG_RETHUNK
> +RETHUNK_CFLAGS := -mfunction-return=thunk-extern
> +RETPOLINE_CFLAGS += $(RETHUNK_CFLAGS)
> +endif
Does Rust have the equivalent of -mfunction-return=thunk-extern ?
Related, how does Rust deal with all the various CC_HAS_ Kconfig stuff?
What if C has the relevant option but Rust does not; then we must not
have the feature enabled or there will be a mis-match.
Do we now have to litter everythign with RUSTC_HAS_ ?
On Wed, Jul 13, 2022 at 1:40 PM Peter Zijlstra <[email protected]> wrote:
>
> Does Rust have the equivalent of -mfunction-return=thunk-extern ?
While GCC has had it for a while, Nick just landed 2 days ago the
X86ReturnThunks pass in LLVM, so it will take some time to arrive in
rustc.
I have naively backported it to rustc and hacked it so that I set the
LLVM attribute for all functions, and I am getting the rets replaced
in Rust functions, e.g.
(gdb) disassemble a::f
Dump of assembler code for function _ZN1a1f17hdc6112b1b4a4fe99E:
...
0x0000000000008a1f <+31>: pop %rbp
0x0000000000008a20 <+32>: jmp 0x8ce0 <__x86_return_thunk>
A trivial userspace program that counts the times that it goes through
the return thunk also appears to work.
> Related, how does Rust deal with all the various CC_HAS_ Kconfig stuff?
> What if C has the relevant option but Rust does not; then we must not
> have the feature enabled or there will be a mis-match.
I guess that would depend on the particular option: whether it applies
to Rust at all, whether it creates an incompatibility or not, etc.
> Do we now have to litter everythign with RUSTC_HAS_ ?
Why? Only a single `rustc` version is targeted at the moment, so it is
possible to statically know what it supports.
And later on, when we can declare a minimum version or when a second
compiler is ready, sure, we may need to have options depending on what
we want to do. Why would that be a problem?
Cheers,
Miguel
On Fri, Jul 15, 2022 at 03:13:17AM +0200, Miguel Ojeda wrote:
> On Wed, Jul 13, 2022 at 1:40 PM Peter Zijlstra <[email protected]> wrote:
> >
> > Does Rust have the equivalent of -mfunction-return=thunk-extern ?
>
> While GCC has had it for a while, Nick just landed 2 days ago the
> X86ReturnThunks pass in LLVM, so it will take some time to arrive in
> rustc.
>
> I have naively backported it to rustc and hacked it so that I set the
> LLVM attribute for all functions, and I am getting the rets replaced
> in Rust functions, e.g.
>
> (gdb) disassemble a::f
> Dump of assembler code for function _ZN1a1f17hdc6112b1b4a4fe99E:
> ...
> 0x0000000000008a1f <+31>: pop %rbp
> 0x0000000000008a20 <+32>: jmp 0x8ce0 <__x86_return_thunk>
>
> A trivial userspace program that counts the times that it goes through
> the return thunk also appears to work.
Ok; I'm supposing that'll be sorted by the time rust happens.
> > Related, how does Rust deal with all the various CC_HAS_ Kconfig stuff?
> > What if C has the relevant option but Rust does not; then we must not
> > have the feature enabled or there will be a mis-match.
>
> I guess that would depend on the particular option: whether it applies
> to Rust at all, whether it creates an incompatibility or not, etc.
There's quite a few things affecting code-gen; rustc not using the exact
same compiler arguments is going to create a head-ache.
> > Do we now have to litter everythign with RUSTC_HAS_ ?
>
> Why? Only a single `rustc` version is targeted at the moment, so it is
> possible to statically know what it supports.
But does it support everything clang does now? If not, you need to
express that in Kconfig and disable the features it doesn't carry. So
even for a single rustc version will you need RUSTC_HAS_ stuff.
What about CC_HAS_IBT? Can rust generate sane IBT code? Current next
doesn't seem to have anything there, suggesting I can't build an IBT
enabled kernel if rust is on (or rather, it'll build, but it'll also
burn at boot).
What if LLVM were to grow -mindirect-branch-cs-prefix (please!) and rust
doesn't have it? Same if LLVM finally stops generating those pesky
conditional tail-calls, will rust continue emitting them?
I'm thinking of the kCFI work, will rustc support that from day 1 or
will that only work when not building any rust.
There being a single rustc is not a single target, every compiler
version grows (and breaks) new features. And for some reason we seem to
change the actual kernel calling convetion a lot of late :/
Currently we can support a feature when one compiler version supports it
(either gcc or clang), but the moment rust becomes a mandatory part of
the kernel build (and I dread that day) we'll need to
wait/update/wrangle at least two different toolchains to implement the
feature in a consistent manner before we can use it.
I also don't see any RUST -mfentry support...
On Fri, Jul 15, 2022 at 11:02 AM Peter Zijlstra <[email protected]> wrote:
>
> Ok; I'm supposing that'll be sorted by the time rust happens.
No, it most likely won't, and I don't see why you would assume that,
or why we would want to block Rust support on that.
> There's quite a few things affecting code-gen; rustc not using the exact
> same compiler arguments is going to create a head-ache.
Yes, a GCC-like driver in `rustc` would be nice for projects like the
kernel. The GCC Rust project will support GCC-like flags, as far as I
understand.
(Cc'ing Antoni, Arthur, Josh, Philip).
> But does it support everything clang does now? If not, you need to
> express that in Kconfig and disable the features it doesn't carry. So
> even for a single rustc version will you need RUSTC_HAS_ stuff.
You could still make everything work around the `RUST` symbol, no need
to "litter everything" (as you said) just yet. :)
> What about CC_HAS_IBT? Can rust generate sane IBT code? Current next
> doesn't seem to have anything there, suggesting I can't build an IBT
> enabled kernel if rust is on (or rather, it'll build, but it'll also
> burn at boot).
>
> What if LLVM were to grow -mindirect-branch-cs-prefix (please!) and rust
> doesn't have it? Same if LLVM finally stops generating those pesky
> conditional tail-calls, will rust continue emitting them?
>
> I'm thinking of the kCFI work, will rustc support that from day 1 or
> will that only work when not building any rust.
>
> There being a single rustc is not a single target, every compiler
> version grows (and breaks) new features. And for some reason we seem to
> change the actual kernel calling convetion a lot of late :/
>
> Currently we can support a feature when one compiler version supports it
> (either gcc or clang), but the moment rust becomes a mandatory part of
> the kernel build (and I dread that day) we'll need to
> wait/update/wrangle at least two different toolchains to implement the
> feature in a consistent manner before we can use it.
>
> I also don't see any RUST -mfentry support...
I think you are getting way too ahead.
Merging the Rust support now is meant to evaluate whether Rust _as a
language_ makes sense for the kernel, whether we can write enough % of
kernel code in the safe subset (and whether that brings enough
advantages), etc.
It is not meant to provide "day 1 support" for everything. In fact,
getting merged now is what will allow to grow support for everything
needed everywhere: not just in terms of compiler flags, faster
integration of LLVM codegen/mitigation features in `rustc`, new
frontends and backends (`rustc_codegen_gcc` and GCC Rust), etc.; but
also within the kernel, in terms of safe abstractions for kernel APIs,
kernel maintainers' experience with Rust, etc.
Cheers,
Miguel
On Mon, Jul 25, 2022 at 10:41 AM Stephen Rothwell <[email protected]> wrote:
>
> Today's linux-next merge of the rust tree got a conflict in:
>
> arch/x86/Makefile
Looks fine to me (I did it a bit differently on my side, but it does
not matter).
Thanks!
Cheers,
Miguel