| Message ID | 20220927131518.30000-26-ojeda@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Rust support | expand |
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>
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. 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 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, 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 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 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
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 Thu, Oct 12, 2023 at 03:15:12PM -0700, Ramon de C Valle wrote: > [1]: > https://doc.rust-lang.org/nightly/unstable-book/language-features/cfi-encoding.html I'm sorry, but that looks like a comment from where I'm sitting :-( Worst part is it being on a line of it's own and thus unrelated to anything. This rust syntax is horrific.. > [2]: > https://doc.rust-lang.org/book/ch19-04-advanced-types.html#using-the-newtype-pattern-for-type-safety-and-abstraction I don't speak enough rust to even begin following this :/ > [3]: Wrapping a type in a struct should achieve something similar even > without using the cfi_encoding attribute since the encoding for structs in > both are <length><name>, where <name> is <unscoped-name>. You're not talking about C, right?
On Fri, Oct 13, 2023 at 12:50 AM Peter Zijlstra <peterz@infradead.org> wrote: > > On Thu, Oct 12, 2023 at 03:15:12PM -0700, Ramon de C Valle wrote: > > > [1]: > > https://doc.rust-lang.org/nightly/unstable-book/language-features/cfi-encoding.html > > I'm sorry, but that looks like a comment from where I'm sitting :-( > Worst part is it being on a line of it's own and thus unrelated to > anything. > > This rust syntax is horrific.. I understand where you're coming from. I'm still getting used to Rust syntax. > > > > [2]: > > https://doc.rust-lang.org/book/ch19-04-advanced-types.html#using-the-newtype-pattern-for-type-safety-and-abstraction > > I don't speak enough rust to even begin following this :/ > > > [3]: Wrapping a type in a struct should achieve something similar even > > without using the cfi_encoding attribute since the encoding for structs in > > both are <length><name>, where <name> is <unscoped-name>. > > You're not talking about C, right? Both C and repr(C) Rust structs have this encoding, but I understand the problems with doing this in C since it doesn't have repr(transparent) structs so there would be a lot of casting back and forth. Maybe there is an alternative or this could be done for less used function pairs?
On Fri, 13 Oct 2023 at 05:18, Ramon de C Valle <rcvalle@google.com> wrote: > > Both C and repr(C) Rust structs have this encoding, but I understand > the problems with doing this in C since it doesn't have > repr(transparent) structs so there would be a lot of casting back and > forth. Maybe there is an alternative or this could be done for less > used function pairs? We actually have some C variations of what I think people want to use "repr(transparent) struct" for in Rust. Of course, that is depending on what kind of context you want to use it for, and I might have lost some background. But I'm assuming you're talking about the situation where you want to treat two or more types as being "compatible" within certain contexts. There's the actual standard C "_Generic()" alternative, which allows you to make macros etc that use different types transparently. It's not very widely used in the kernel, because we only fairly recently moved to require recent enough compiler versions, but we do use it now in a couple of places. And there's the much more traditional gcc extension in the form of the __attribute__((__transparent_union__)) thing. In the kernel, that one is even less used, and that one use is likely going away since the need for it is going away. But while it's not standard C, it's actually been supported by relevant compilers for much longer than "_Generic" has, and is designed exactly for the "I have a function that can take arguments of different types", either because the types are bitwise identical (even if _conceptually_ not the same), or simply because you have a different argument that describes the type (the traditional C union model). I suspect, for example, that we *should* have used those transparent unions for the "this function can take either a folio or a page" case, instead of duplicating functions for the two uses. But probably because few people aren familiar with the syntax, that's not what happened. Linus
On October 13, 2023 11:54:46 AM PDT, Linus Torvalds <torvalds@linux-foundation.org> wrote: >On Fri, 13 Oct 2023 at 05:18, Ramon de C Valle <rcvalle@google.com> wrote: >> >> Both C and repr(C) Rust structs have this encoding, but I understand >> the problems with doing this in C since it doesn't have >> repr(transparent) structs so there would be a lot of casting back and >> forth. Maybe there is an alternative or this could be done for less >> used function pairs? > >We actually have some C variations of what I think people want to use >"repr(transparent) struct" for in Rust. > >Of course, that is depending on what kind of context you want to use >it for, and I might have lost some background. But I'm assuming you're >talking about the situation where you want to treat two or more types >as being "compatible" within certain contexts. > >There's the actual standard C "_Generic()" alternative, which allows >you to make macros etc that use different types transparently. > >It's not very widely used in the kernel, because we only fairly >recently moved to require recent enough compiler versions, but we do >use it now in a couple of places. > >And there's the much more traditional gcc extension in the form of the >__attribute__((__transparent_union__)) thing. In the kernel, that one >is even less used, and that one use is likely going away since the >need for it is going away. > >But while it's not standard C, it's actually been supported by >relevant compilers for much longer than "_Generic" has, and is >designed exactly for the "I have a function that can take arguments of >different types", either because the types are bitwise identical (even >if _conceptually_ not the same), or simply because you have a >different argument that describes the type (the traditional C union >model). > >I suspect, for example, that we *should* have used those transparent >unions for the "this function can take either a folio or a page" case, >instead of duplicating functions for the two uses. > >But probably because few people aren familiar with the syntax, that's >not what happened. > > Linus Transparent unions have been standard C since C99.
On Fri, 13 Oct 2023 at 12:01, H. Peter Anvin <hpa@zytor.com> wrote: > > Transparent unions have been standard C since C99. Ahh, I didn't realize they made it into the standard. In gcc, they've been usable for a lot longer (ie --std=gnu89 certainly is happy with them), but the kernel never really picked up on them. I think they've mainly been used by glibc for a couple of functions that can take a couple of different types without complaining. Linus
> On Oct 13, 2023, at 12:00 PM, H. Peter Anvin <hpa@zytor.com> wrote: > > Transparent unions have been standard C since C99. I don’t think that’s right. Certainly __attribute__((transparent_union)) is not standard C; are you referring to a different feature?
On October 14, 2023 1:25:12 PM PDT, comex <comexk@gmail.com> wrote: > > >> On Oct 13, 2023, at 12:00 PM, H. Peter Anvin <hpa@zytor.com> wrote: >> >> Transparent unions have been standard C since C99. > >I don’t think that’s right. Certainly __attribute__((transparent_union)) is not standard C; are you referring to a different feature? > My mistake... I was thinking about anonymous unions.
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"); }