Note that only x86_64 is covered and not all features nor mitigations
are handled, but it is enough as a starting point and showcases
the basics needed to add Rust support for a new architecture.
Reviewed-by: Kees Cook <keescook@chromium.org>
Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com>
Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com>
Co-developed-by: Wedson Almeida Filho <wedsonaf@google.com>
Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com>
Co-developed-by: David Gow <davidgow@google.com>
Signed-off-by: David Gow <davidgow@google.com>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
Documentation/rust/arch-support.rst | 1 +
arch/x86/Kconfig | 1 +
arch/x86/Makefile | 10 ++++++++++
scripts/generate_rust_target.rs | 15 +++++++++++++--
4 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/Documentation/rust/arch-support.rst b/Documentation/rust/arch-support.rst
index 1152e0fbdad0..6982b63775da 100644
--- a/Documentation/rust/arch-support.rst
+++ b/Documentation/rust/arch-support.rst
@@ -15,4 +15,5 @@ support corresponds to ``S`` values in the ``MAINTAINERS`` file.
============ ================ ==============================================
Architecture Level of support Constraints
============ ================ ==============================================
+``x86`` Maintained ``x86_64`` only.
============ ================ ==============================================
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f9920f1341c8..3ca198742b10 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -257,6 +257,7 @@ config X86
select HAVE_STATIC_CALL_INLINE if HAVE_OBJTOOL
select HAVE_PREEMPT_DYNAMIC_CALL
select HAVE_RSEQ
+ select HAVE_RUST if X86_64
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_UACCESS_VALIDATION if HAVE_OBJTOOL
select HAVE_UNSTABLE_SCHED_CLOCK
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index bafbd905e6e7..2d7e640674c6 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -68,6 +68,7 @@ export BITS
# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383
#
KBUILD_CFLAGS += -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx
+KBUILD_RUSTFLAGS += -Ctarget-feature=-sse,-sse2,-sse3,-ssse3,-sse4.1,-sse4.2,-avx,-avx2
ifeq ($(CONFIG_X86_KERNEL_IBT),y)
#
@@ -155,8 +156,17 @@ else
cflags-$(CONFIG_GENERIC_CPU) += -mtune=generic
KBUILD_CFLAGS += $(cflags-y)
+ rustflags-$(CONFIG_MK8) += -Ctarget-cpu=k8
+ rustflags-$(CONFIG_MPSC) += -Ctarget-cpu=nocona
+ rustflags-$(CONFIG_MCORE2) += -Ctarget-cpu=core2
+ rustflags-$(CONFIG_MATOM) += -Ctarget-cpu=atom
+ rustflags-$(CONFIG_GENERIC_CPU) += -Ztune-cpu=generic
+ KBUILD_RUSTFLAGS += $(rustflags-y)
+
KBUILD_CFLAGS += -mno-red-zone
KBUILD_CFLAGS += -mcmodel=kernel
+ KBUILD_RUSTFLAGS += -Cno-redzone=y
+ KBUILD_RUSTFLAGS += -Ccode-model=kernel
endif
#
diff --git a/scripts/generate_rust_target.rs b/scripts/generate_rust_target.rs
index 7256c9606cf0..3c6cbe2b278d 100644
--- a/scripts/generate_rust_target.rs
+++ b/scripts/generate_rust_target.rs
@@ -148,8 +148,19 @@ fn main() {
let mut ts = TargetSpec::new();
// `llvm-target`s are taken from `scripts/Makefile.clang`.
- if cfg.has("DUMMY_ARCH") {
- ts.push("arch", "dummy_arch");
+ if cfg.has("X86_64") {
+ ts.push("arch", "x86_64");
+ ts.push(
+ "data-layout",
+ "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128",
+ );
+ let mut features = "-3dnow,-3dnowa,-mmx,+soft-float".to_string();
+ if cfg.has("RETPOLINE") {
+ features += ",+retpoline-external-thunk";
+ }
+ ts.push("features", features);
+ ts.push("llvm-target", "x86_64-linux-gnu");
+ ts.push("target-pointer-width", "64");
} else {
panic!("Unsupported architecture");
}
--
2.37.3On Tue, Sep 27, 2022 at 03:14:56PM +0200, Miguel Ojeda wrote: > Note that only x86_64 is covered and not all features nor mitigations > are handled, but it is enough as a starting point and showcases > the basics needed to add Rust support for a new architecture. Does it fail the build if required options are missing? Specifically are things like kCFI and IBT enabled? Silently not handling those will result in an unbootable image. As to missing mitigations; does it at least visibly warn people? I'm very *very* uncomfortable having to 'support' a half-arsed compiler like this.
On Fri, Oct 7, 2022 at 10:18 AM Peter Zijlstra <peterz@infradead.org> wrote: > > On Tue, Sep 27, 2022 at 03:14:56PM +0200, Miguel Ojeda wrote: > > Note that only x86_64 is covered and not all features nor mitigations > > are handled, but it is enough as a starting point and showcases > > the basics needed to add Rust support for a new architecture. > > Does it fail the build if required options are missing? Specifically are > things like kCFI and IBT enabled? Silently not handling those will > result in an unbootable image. Rust supports IBT with -Z cf-protection=branch, but I don't see this option being enabled in the kernel yet. Cross-language CFI is going to require a lot more work though because the type systems are not quite compatible: https://github.com/rust-lang/rfcs/pull/3296 Sami
On Tue, Oct 11, 2022 at 1:16 AM Sami Tolvanen <samitolvanen@google.com> wrote: > > Rust supports IBT with -Z cf-protection=branch, but I don't see this > option being enabled in the kernel yet. Cross-language CFI is going to > require a lot more work though because the type systems are not quite > compatible: > > https://github.com/rust-lang/rfcs/pull/3296 I have pinged Ramon de C Valle as he is the author of the RFC above and implementation work too; since a month or so ago he also leads the Exploit Mitigations Project Group in Rust. Cheers, Miguel
On Fri, Oct 14, 2022 at 11:05 AM Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > > On Tue, Oct 11, 2022 at 1:16 AM Sami Tolvanen <samitolvanen@google.com> wrote: > > > > Rust supports IBT with -Z cf-protection=branch, but I don't see this > > option being enabled in the kernel yet. Cross-language CFI is going to > > require a lot more work though because the type systems are not quite > > compatible: > > > > https://github.com/rust-lang/rfcs/pull/3296 > > I have pinged Ramon de C Valle as he is the author of the RFC above > and implementation work too; since a month or so ago he also leads the > Exploit Mitigations Project Group in Rust. Thanks, Miguel. I also talked to Ramon about KCFI earlier this week and he expressed interest in helping with rustc support for it. In the meanwhile, I think we can just add a depends on !CFI_CLANG to avoid issues here. Sami
On Fri, Oct 14, 2022 at 11:34:30AM -0700, Sami Tolvanen wrote: > On Fri, Oct 14, 2022 at 11:05 AM Miguel Ojeda > <miguel.ojeda.sandonis@gmail.com> wrote: > > > > On Tue, Oct 11, 2022 at 1:16 AM Sami Tolvanen <samitolvanen@google.com> wrote: > > > > > > Rust supports IBT with -Z cf-protection=branch, but I don't see this > > > option being enabled in the kernel yet. Cross-language CFI is going to > > > require a lot more work though because the type systems are not quite > > > compatible: > > > > > > https://github.com/rust-lang/rfcs/pull/3296 > > > > I have pinged Ramon de C Valle as he is the author of the RFC above > > and implementation work too; since a month or so ago he also leads the > > Exploit Mitigations Project Group in Rust. > > Thanks, Miguel. I also talked to Ramon about KCFI earlier this week > and he expressed interest in helping with rustc support for it. In the > meanwhile, I think we can just add a depends on !CFI_CLANG to avoid > issues here. Having just read up on the thing it looks like the KCFI thing is resolved. I'm not sure I understand most of the objections in that thread through -- enabling CFI *will* break stuff, so what. Squashing the integer types seems a workable compromise I suppose. One thing that's been floated in the past is adding a 'seed' attribute to some functions in order to distinguish functions of otherwise identical signature. The Rust thing would then also need to support this attribute. Are there any concrete plans for this? It would allow, for example, to differentiate address_space_operations::swap_deactivate() from any other random function that takes only a file argument, say: locks_remove_file().
On Thu, Oct 12, 2023 at 3:47 AM Peter Zijlstra <peterz@infradead.org> wrote: > > On Fri, Oct 14, 2022 at 11:34:30AM -0700, Sami Tolvanen wrote: > > On Fri, Oct 14, 2022 at 11:05 AM Miguel Ojeda > > <miguel.ojeda.sandonis@gmail.com> wrote: > > > > > > On Tue, Oct 11, 2022 at 1:16 AM Sami Tolvanen <samitolvanen@google.com> wrote: > > > > > > > > Rust supports IBT with -Z cf-protection=branch, but I don't see this > > > > option being enabled in the kernel yet. Cross-language CFI is going to > > > > require a lot more work though because the type systems are not quite > > > > compatible: > > > > > > > > https://github.com/rust-lang/rfcs/pull/3296 > > > > > > I have pinged Ramon de C Valle as he is the author of the RFC above > > > and implementation work too; since a month or so ago he also leads the > > > Exploit Mitigations Project Group in Rust. > > > > Thanks, Miguel. I also talked to Ramon about KCFI earlier this week > > and he expressed interest in helping with rustc support for it. In the > > meanwhile, I think we can just add a depends on !CFI_CLANG to avoid > > issues here. > > Having just read up on the thing it looks like the KCFI thing is > resolved. > > I'm not sure I understand most of the objections in that thread through > -- enabling CFI *will* break stuff, so what. > > Squashing the integer types seems a workable compromise I suppose. One > thing that's been floated in the past is adding a 'seed' attribute to > some functions in order to distinguish functions of otherwise identical > signature. > > The Rust thing would then also need to support this attribute. > > Are there any concrete plans for this? It would allow, for example, > to differentiate address_space_operations::swap_deactivate() from any > other random function that takes only a file argument, say: > locks_remove_file(). I haven't really had time to look into it, so no concrete plans yet. Adding an attribute shouldn't be terribly difficult, but Kees expressed interest in automatic salting as well, which might be a more involved project: https://github.com/ClangBuiltLinux/linux/issues/1736 Sami
On Thu, Oct 12, 2023 at 10:50:36AM -0700, Sami Tolvanen wrote: > On Thu, Oct 12, 2023 at 3:47 AM Peter Zijlstra <peterz@infradead.org> wrote: > > > > On Fri, Oct 14, 2022 at 11:34:30AM -0700, Sami Tolvanen wrote: > > > On Fri, Oct 14, 2022 at 11:05 AM Miguel Ojeda > > > <miguel.ojeda.sandonis@gmail.com> wrote: > > > > > > > > On Tue, Oct 11, 2022 at 1:16 AM Sami Tolvanen <samitolvanen@google.com> wrote: > > > > > > > > > > Rust supports IBT with -Z cf-protection=branch, but I don't see this > > > > > option being enabled in the kernel yet. Cross-language CFI is going to > > > > > require a lot more work though because the type systems are not quite > > > > > compatible: > > > > > > > > > > https://github.com/rust-lang/rfcs/pull/3296 > > > > > > > > I have pinged Ramon de C Valle as he is the author of the RFC above > > > > and implementation work too; since a month or so ago he also leads the > > > > Exploit Mitigations Project Group in Rust. > > > > > > Thanks, Miguel. I also talked to Ramon about KCFI earlier this week > > > and he expressed interest in helping with rustc support for it. In the > > > meanwhile, I think we can just add a depends on !CFI_CLANG to avoid > > > issues here. > > > > Having just read up on the thing it looks like the KCFI thing is > > resolved. > > > > I'm not sure I understand most of the objections in that thread through > > -- enabling CFI *will* break stuff, so what. > > > > Squashing the integer types seems a workable compromise I suppose. One > > thing that's been floated in the past is adding a 'seed' attribute to > > some functions in order to distinguish functions of otherwise identical > > signature. > > > > The Rust thing would then also need to support this attribute. > > > > Are there any concrete plans for this? It would allow, for example, > > to differentiate address_space_operations::swap_deactivate() from any > > other random function that takes only a file argument, say: > > locks_remove_file(). > > I haven't really had time to look into it, so no concrete plans yet. > Adding an attribute shouldn't be terribly difficult, but Kees > expressed interest in automatic salting as well, which might be a more > involved project: > > https://github.com/ClangBuiltLinux/linux/issues/1736 Automatic would be nice, but having an attribute would let us at least start the process manually (or apply salting from static analysis output, etc). -Kees -- Kees Cook
On Thu, Oct 12, 2023 at 11:31 AM Kees Cook <keescook@chromium.org> wrote: > > On Thu, Oct 12, 2023 at 10:50:36AM -0700, Sami Tolvanen wrote: > > On Thu, Oct 12, 2023 at 3:47 AM Peter Zijlstra <peterz@infradead.org> wrote: > > > > > > On Fri, Oct 14, 2022 at 11:34:30AM -0700, Sami Tolvanen wrote: > > > > On Fri, Oct 14, 2022 at 11:05 AM Miguel Ojeda > > > > <miguel.ojeda.sandonis@gmail.com> wrote: > > > > > > > > > > On Tue, Oct 11, 2022 at 1:16 AM Sami Tolvanen <samitolvanen@google.com> wrote: > > > > > > > > > > > > Rust supports IBT with -Z cf-protection=branch, but I don't see this > > > > > > option being enabled in the kernel yet. Cross-language CFI is going to > > > > > > require a lot more work though because the type systems are not quite > > > > > > compatible: > > > > > > > > > > > > https://github.com/rust-lang/rfcs/pull/3296 > > > > > > > > > > I have pinged Ramon de C Valle as he is the author of the RFC above > > > > > and implementation work too; since a month or so ago he also leads the > > > > > Exploit Mitigations Project Group in Rust. > > > > > > > > Thanks, Miguel. I also talked to Ramon about KCFI earlier this week > > > > and he expressed interest in helping with rustc support for it. In the > > > > meanwhile, I think we can just add a depends on !CFI_CLANG to avoid > > > > issues here. > > > > > > Having just read up on the thing it looks like the KCFI thing is > > > resolved. > > > > > > I'm not sure I understand most of the objections in that thread through > > > -- enabling CFI *will* break stuff, so what. > > > > > > Squashing the integer types seems a workable compromise I suppose. One > > > thing that's been floated in the past is adding a 'seed' attribute to > > > some functions in order to distinguish functions of otherwise identical > > > signature. > > > > > > The Rust thing would then also need to support this attribute. > > > > > > Are there any concrete plans for this? It would allow, for example, > > > to differentiate address_space_operations::swap_deactivate() from any > > > other random function that takes only a file argument, say: > > > locks_remove_file(). > > > > I haven't really had time to look into it, so no concrete plans yet. > > Adding an attribute shouldn't be terribly difficult, but Kees > > expressed interest in automatic salting as well, which might be a more > > involved project: > > > > https://github.com/ClangBuiltLinux/linux/issues/1736 > > Automatic would be nice, but having an attribute would let us at least > start the process manually (or apply salting from static analysis > output, etc). An idea would be to add something like the Rust cfi_encoding attribute[1] and use it with something similar to the Newtype Pattern[2], but in C[3], for aggregating function pointers that otherwise would be aggregated in the same group in different groups. [1]: https://doc.rust-lang.org/nightly/unstable-book/language-features/cfi-encoding.html [2]: https://doc.rust-lang.org/book/ch19-04-advanced-types.html#using-the-newtype-pattern-for-type-safety-and-abstraction [3]: Wrapping a type in a struct should achieve something similar even without using the cfi_encoding attribute since the encoding for structs is <length><name>, where <name> is <unscoped-name>.
On Fri, Oct 14, 2022 at 8:35 PM Sami Tolvanen <samitolvanen@google.com> wrote: > > Thanks, Miguel. I also talked to Ramon about KCFI earlier this week > and he expressed interest in helping with rustc support for it. In the Ah, that is great to hear -- thanks a lot to you both! (Cc'ing Ramon) > meanwhile, I think we can just add a depends on !CFI_CLANG to avoid > issues here. ACK, thanks -- if you want to send the patch, please feel free to do so. Cheers, Miguel
I have a patchset enabling support for both KCFI and IBT in the kernel, but it uses changes not yet landed in stable rustc, which is why I haven't sent it to the list yet: https://github.com/Rust-for-Linux/linux/pull/1034 We've backported the changes to rustc that need to be present onto the Android copy of the compiler, but it will take 6-12 weeks for them to hit stable rustc, which is what general Linux is using. If the IBT part would be helpful by itself immediately, I can split that out - it's only the KCFI portion that won't currently work. On Fri, Oct 14, 2022 at 1:40 PM Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > > On Fri, Oct 14, 2022 at 8:35 PM Sami Tolvanen <samitolvanen@google.com> wrote: > > > > Thanks, Miguel. I also talked to Ramon about KCFI earlier this week > > and he expressed interest in helping with rustc support for it. In the > > Ah, that is great to hear -- thanks a lot to you both! (Cc'ing Ramon) > > > meanwhile, I think we can just add a depends on !CFI_CLANG to avoid > > issues here. > > ACK, thanks -- if you want to send the patch, please feel free to do so. > > Cheers, > Miguel
On Mon, Oct 9, 2023 at 6:01 PM Matthew Maurer <mmaurer@google.com> wrote: > > If the IBT part would be helpful by itself immediately, I can split > that out - it's only the KCFI portion that won't currently work. Thanks Matthew. I don't think we are in a rush, but if it is not too much work to split it, that would be great, instead of adding the restriction. For retthunk, by the way, I forgot to mention to Greg above that (in the original discussion with PeterZ) that I did a quick test back then to hack the equivalent of `-mfunction-return=thunk-extern` into `rustc` to show that the compiler could use it via LLVM (by passing the attribute in the IR). At least at a basic level it seemed to work: I got a userspace program to count the times that it went through the return thunk. I didn't try to do anything on the kernel side, but at least for the compiler side, it seemed OK. So it may be way easier (on the compiler side) than the CFI work? Cheers, Miguel
On Mon, Oct 09, 2023 at 06:31:13PM +0200, Miguel Ojeda wrote: > On Mon, Oct 9, 2023 at 6:01 PM Matthew Maurer <mmaurer@google.com> wrote: > > > > If the IBT part would be helpful by itself immediately, I can split > > that out - it's only the KCFI portion that won't currently work. > > Thanks Matthew. I don't think we are in a rush, but if it is not too > much work to split it, that would be great, instead of adding the > restriction. > > For retthunk, by the way, I forgot to mention to Greg above that (in > the original discussion with PeterZ) that I did a quick test back then > to hack the equivalent of `-mfunction-return=thunk-extern` into > `rustc` to show that the compiler could use it via LLVM (by passing > the attribute in the IR). At least at a basic level it seemed to work: > I got a userspace program to count the times that it went through the > return thunk. I didn't try to do anything on the kernel side, but at > least for the compiler side, it seemed OK. So it may be way easier (on > the compiler side) than the CFI work? It should hopefully be much easier than CFI, it was a much simpler change to gcc and clang when it landed. thanks, greg k-h
On Mon, Oct 10, 2022 at 04:15:33PM -0700, Sami Tolvanen wrote: > On Fri, Oct 7, 2022 at 10:18 AM Peter Zijlstra <peterz@infradead.org> wrote: > > > > On Tue, Sep 27, 2022 at 03:14:56PM +0200, Miguel Ojeda wrote: > > > Note that only x86_64 is covered and not all features nor mitigations > > > are handled, but it is enough as a starting point and showcases > > > the basics needed to add Rust support for a new architecture. > > > > Does it fail the build if required options are missing? Specifically are > > things like kCFI and IBT enabled? Silently not handling those will > > result in an unbootable image. > > Rust supports IBT with -Z cf-protection=branch, but I don't see this > option being enabled in the kernel yet. Cross-language CFI is going to > require a lot more work though because the type systems are not quite > compatible: Right; so where does that leave us? Are we going to force disable rust when kCFI is selected ?
On Tue, Oct 11, 2022 at 10:04 AM Peter Zijlstra <peterz@infradead.org> wrote: > > Right; so where does that leave us? Are we going to force disable rust > when kCFI is selected ? Constraining it via `depends on !...` or similar as needed for the moment is fine, we have a few others too. Cheers, Miguel
On Fri, Oct 14, 2022 at 07:23:18PM +0200, Miguel Ojeda wrote: > On Tue, Oct 11, 2022 at 10:04 AM Peter Zijlstra <peterz@infradead.org> wrote: > > > > Right; so where does that leave us? Are we going to force disable rust > > when kCFI is selected ? > > Constraining it via `depends on !...` or similar as needed for the > moment is fine, we have a few others too. > Right, and Peter, we actually need your help to figure out which configs are related ;-) Regards, Boqun > Cheers, > Miguel
On Tue, Sep 27, 2022 at 03:14:56PM +0200, Miguel Ojeda wrote: > Note that only x86_64 is covered and not all features nor mitigations > are handled, but it is enough as a starting point and showcases > the basics needed to add Rust support for a new architecture. > > Reviewed-by: Kees Cook <keescook@chromium.org> > Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> > Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> > Co-developed-by: Wedson Almeida Filho <wedsonaf@google.com> > Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com> > Co-developed-by: David Gow <davidgow@google.com> > Signed-off-by: David Gow <davidgow@google.com> > Signed-off-by: Miguel Ojeda <ojeda@kernel.org> > --- > Documentation/rust/arch-support.rst | 1 + > arch/x86/Kconfig | 1 + > arch/x86/Makefile | 10 ++++++++++ > scripts/generate_rust_target.rs | 15 +++++++++++++-- > 4 files changed, 25 insertions(+), 2 deletions(-) > > diff --git a/Documentation/rust/arch-support.rst b/Documentation/rust/arch-support.rst > index 1152e0fbdad0..6982b63775da 100644 > --- a/Documentation/rust/arch-support.rst > +++ b/Documentation/rust/arch-support.rst > @@ -15,4 +15,5 @@ support corresponds to ``S`` values in the ``MAINTAINERS`` file. > ============ ================ ============================================== > Architecture Level of support Constraints > ============ ================ ============================================== > +``x86`` Maintained ``x86_64`` only. > ============ ================ ============================================== > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index f9920f1341c8..3ca198742b10 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -257,6 +257,7 @@ config X86 > select HAVE_STATIC_CALL_INLINE if HAVE_OBJTOOL > select HAVE_PREEMPT_DYNAMIC_CALL > select HAVE_RSEQ > + select HAVE_RUST if X86_64 > select HAVE_SYSCALL_TRACEPOINTS > select HAVE_UACCESS_VALIDATION if HAVE_OBJTOOL > select HAVE_UNSTABLE_SCHED_CLOCK > diff --git a/arch/x86/Makefile b/arch/x86/Makefile > index bafbd905e6e7..2d7e640674c6 100644 > --- a/arch/x86/Makefile > +++ b/arch/x86/Makefile > @@ -68,6 +68,7 @@ export BITS > # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383 > # > KBUILD_CFLAGS += -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx > +KBUILD_RUSTFLAGS += -Ctarget-feature=-sse,-sse2,-sse3,-ssse3,-sse4.1,-sse4.2,-avx,-avx2 I do wonder how many more things you will need to list here. As far as I can tell there is also other avx512* flags for the x86_64 target. That said, if this works today ... Reviewed-by: Wei Liu <wei.liu@kernel.org>
On Wed, Sep 28, 2022 at 4:32 PM Wei Liu <wei.liu@kernel.org> wrote: > > I do wonder how many more things you will need to list here. As far as > I can tell there is also other avx512* flags for the x86_64 target. Yeah, there are a lot of target features, but they are not getting enabled. Eventually, a stable target spec alternative (e.g. all relevant target feature flags) should be available, and then we can know what the guaranteed behavior will be and thus decide better which flags to keep or not depending on how explicit we want to be with respect to that. For the moment I went for consistency with the line above, since that was enough to disable everything we needed, though as you may have noticed, 3dnow and mmx are not there, because I had to move them back to the target spec [1]. [1] https://github.com/Rust-for-Linux/linux/commit/c5eae3a6e69c63dc8d69f51f74f74b853831ec71 Cheers, Miguel
On Tue, Sep 27, 2022 at 03:14:56PM +0200, Miguel Ojeda wrote: > Note that only x86_64 is covered and not all features nor mitigations > are handled, but it is enough as a starting point and showcases > the basics needed to add Rust support for a new architecture. > > Reviewed-by: Kees Cook <keescook@chromium.org> > Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> > Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> > Co-developed-by: Wedson Almeida Filho <wedsonaf@google.com> > Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com> > Co-developed-by: David Gow <davidgow@google.com> > Signed-off-by: David Gow <davidgow@google.com> > Signed-off-by: Miguel Ojeda <ojeda@kernel.org> > --- > Documentation/rust/arch-support.rst | 1 + > arch/x86/Kconfig | 1 + > arch/x86/Makefile | 10 ++++++++++ > scripts/generate_rust_target.rs | 15 +++++++++++++-- > 4 files changed, 25 insertions(+), 2 deletions(-) Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
© 2016 - 2026 Red Hat, Inc.