linux-kernel - Re: [PATCH v4 16/20] 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: <CANiq72mdru-MyP_QoRSpKu1bhB8v5sZNs8mvGdWsJp7NfXE+bQ@mail.gmail.com>
Date:   Sat, 12 Feb 2022 19:32:10 +0100
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Miguel Ojeda <ojeda@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        rust-for-linux <rust-for-linux@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Alex Gaynor <alex.gaynor@...il.com>,
        Finn Behrens <me@...enk.de>,
        Adam Bratschi-Kaye <ark.email@...il.com>,
        Wedson Almeida Filho <wedsonaf@...gle.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Sven Van Asbroeck <thesven73@...il.com>,
        Gary Guo <gary@...yguo.net>,
        Boris-Chengbiao Zhou <bobo1239@....de>,
        Boqun Feng <boqun.feng@...il.com>,
        Douglas Su <d0u9.su@...look.com>,
        Dariusz Sosnowski <dsosnowski@...snowski.pl>,
        Antonio Terceiro <antonio.terceiro@...aro.org>,
        Daniel Xu <dxu@...uu.xyz>, Miguel Cano <macanroj@...il.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        linux-riscv <linux-riscv@...ts.infradead.org>
Subject: Re: [PATCH v4 16/20] Kbuild: add Rust support

On Sat, Feb 12, 2022 at 5:19 PM Russell King (Oracle)
<linux@...linux.org.uk> wrote:
>
> Right, so why made it dependent on CPU_32v6 || CPU_32v6K if ARMv7 is
> supported? What about CPU_32v7? What about CPU_32v7M?
>
> I think it would be saner to use the CPU_V6, CPU_V6K, CPU_V7 and maybe
> CPU_V7M here - even bettern to select "HAVE_RUST" from these symbols,
> since I'm sure you'd start to see the issue behind my "HAVE_RUST"
> suggestion as it means having four symbols just for 32-bit ARM on your
> dependency line.

To support arch variations properly we also have to configure the
compiler via filling a target spec on the fly, but so far we only have
a few static variations as an example. This is one of the missing
parts of the arch support. I will let you know when we have something
ready.

> Interestingly, it does not list arm-unknown-linux-gnueabihf, which
> is the "tuple" commonly used to build 32-bit ARM kernels.

I see it there (Tier 2).

> Probably because people incorrectly think it's required or some other
> minor reason. As I say:

In that case, we should remove them and warn about those instances,
assuming the preferred style is to not have it.

> so using the argument
> that there are "500+ instances" and therefore should be seen as
> correct is completely misguided.

I did not use any such argument.

> I mean, if we end up with, e.g. a filesystem coded in Rust, that
> filesystem will not be available on architectures that the kernel

As long as that filesystem is an optional feature (or as long as there
is a C version), it should be fine.

> supports until either (a) Rust gains support for that architecture

For this, it would be ideal if entities behind some of the
architectures could support LLVM & ClangBuiltLinux, or the GCC Rust
frontend, or the GCC backend for `rustc`.

For instance, Arm is supporting both LLVM and the Rust project.

> or (b) someone re-codes the filesystem in C - at which point, what
> is the point of having Rust in the kernel?

Having a C version of some system does not mean a Rust version would
not offer advantages. In fact, we are adding Rust precisely because we
believe it offers some advantages over C, for both end users and
maintainers.

(Please see the RFC [1], previous discussions, etc.)

[1] https://lore.kernel.org/lkml/20210414184604.23473-1-ojeda@kernel.org/

Cheers,
Miguel