linux-kernel - Re: [PATCH v8 27/31] Kbuild: add Rust support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72mp4pgfszjM5t6zgLOBFTmUO4oZkbMxHhekbiNwUe9YLw@mail.gmail.com>
Date:   Thu, 18 Aug 2022 00:42:37 +0200
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Björn Roy Baron <bjorn3_gh@...tonmail.com>
Cc:     Arnd Bergmann <arnd@...db.de>, Miguel Ojeda <ojeda@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Sven Van Asbroeck <thesven73@...il.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Miguel Cano <macanroj@...il.com>,
        Paul Mackerras <paulus@...ba.org>, Gary Guo <gary@...yguo.net>,
        Douglas Su <d0u9.su@...look.com>,
        Borislav Petkov <bp@...en8.de>,
        linux-riscv@...ts.infradead.org, Will Deacon <will@...nel.org>,
        Martin Rodriguez Reboredo <yakoyoku@...il.com>,
        Anton Ivanov <anton.ivanov@...bridgegreys.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Masahiro Yamada <masahiroy@...nel.org>, x86@...nel.org,
        Russell King <linux@...linux.org.uk>,
        Ingo Molnar <mingo@...hat.com>,
        Wedson Almeida Filho <wedsonaf@...gle.com>,
        Alex Gaynor <alex.gaynor@...il.com>,
        Antonio Terceiro <antonio.terceiro@...aro.org>,
        Adam Bratschi-Kaye <ark.email@...il.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        rust-for-linux@...r.kernel.org, linux-kbuild@...r.kernel.org,
        Boqun Feng <boqun.feng@...il.com>,
        linux-um@...ts.infradead.org,
        Michal Marek <michal.lkml@...kovi.net>,
        Daniel Xu <dxu@...uu.xyz>, David Gow <davidgow@...gle.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Dariusz Sosnowski <dsosnowski@...snowski.pl>,
        linux-arm-kernel@...ts.infradead.org,
        Tiago Lam <tiagolam@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        linux-kernel@...r.kernel.org,
        Boris-Chengbiao Zhou <bobo1239@....de>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Palmer Dabbelt <palmer@...belt.com>,
        Richard Weinberger <richard@....at>,
        Finn Behrens <me@...enk.de>,
        Johannes Berg <johannes@...solutions.net>,
        linuxppc-dev@...ts.ozlabs.org,
        Philip Herron <philip.herron@...ecosm.com>,
        Arthur Cohen <arthur.cohen@...ecosm.com>,
        Antoni Boucher <bouanto@...o.com>
Subject: Re: [PATCH v8 27/31] Kbuild: add Rust support

On Wed, Aug 17, 2022 at 6:11 PM Björn Roy Baron
<bjorn3_gh@...tonmail.com> wrote:
>
> There is already a prototype of such a driver. It can be found at https://github.com/Rust-GCC/cargo-gccrs. Unlike what the name suggests it is not cargo specific. It consists of two binaries. The first calls cargo, but tells it to use the second binary instead of a real rustc. This second part then translates all arguments to what gccrs expects. It is possible to directly invoke this second binary. For now it probably won't work for rust-for-linux though as it doesn't have all arguments that are used by rust-for-linux implemented.

I spoke with them about this a few weeks ago, but I thought it was
best to leave it up to the GCC Rust folks to detail how they will
proceed if they already know.

> As alternative to GCC Rust there is also github.com/rust-lang/rustc_codegen_gcc/ which uses libgccjit as backend for the official rust compiler rather than writing a full Rust frontend for GCC from scratch. With a bit of patching to force it to be used, I was able to compile all Rust samples with GCC using rustc_codegen_gcc. However it gives warnings of the following kind:
>
>     ld.lld: warning: rust/built-in.a(core.o):(.data.rel.local) is being placed in '.data.rel.local'
>
> And hangs very early in the boot process. If I enable early logging, it prints up to "Booting the kernel." and then does nothing. This is probably because support for setting a different relocation model is not yet implemented. I opened https://github.com/rust-lang/rustc_codegen_gcc/issues/205 for this.

Thanks Björn for giving it a go!

Arnd maintains a set of cross-GCC binaries for kernel developers, so I
assumed he was mainly interested in including GCC Rust there -- I
didn't mean to leave `rustc_codegen_gcc` aside! :) In fact, a few
weeks ago I also spoke with Antoni (Cc'd too!) about whether he would
be interested in getting it to work with Rust for Linux soon, whether
and how we could help him, etc.

In any case, both GCC Rust and  `rustc_codegen_gcc` will be present in
Kangrejos and LPC (Rust MC), so hopefully we will discuss the details
face-to-face!

> There may be other issues, but rustc_codegen_gcc is probably going to be the easiest route towards a LLVM free rust-for-linux build. By the way note that rust-bindgen which we use for generating rust bindings from C headers depends on LLVM. See https://github.com/rust-lang/rust-bindgen/issues/1949.

Yeah, `rustc_codegen_gcc` is possibly going to happen sooner than GCC
Rust for the kernel.

As for `bindgen`, it is indeed a pain point. There are several
possibilities we have been considering (GCC backend in `bindgen`, an
equivalent tool in GCC, something based on other parsers, something
else entirely, "just checking the results" approaches, even convincing
upstream Rust that C header support would be amazing for Rust
uptake... ;-). Ideally we would get funding to have somebody working
on the problem, but we will see.

Cheers,
Miguel