linux-kernel - Re: [PATCH v1 0/2] RISC-V: enable rust

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: <CANiq72mip7Xs5vnS4KccxCmBmRbKGki7AYTTHxwaeyr3amvSWw@mail.gmail.com>
Date:   Mon, 3 Apr 2023 18:35:45 +0200
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Conor Dooley <conor.dooley@...rochip.com>
Cc:     linux-riscv@...ts.infradead.org, conor@...nel.org,
        Miguel Ojeda <ojeda@...nel.org>,
        Alex Gaynor <alex.gaynor@...il.com>,
        Wedson Almeida Filho <wedsonaf@...il.com>,
        Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
        Björn Roy Baron <bjorn3_gh@...tonmail.com>,
        Jonathan Corbet <corbet@....net>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Tom Rix <trix@...hat.com>, rust-for-linux@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        llvm@...ts.linux.dev
Subject: Re: [PATCH v1 0/2] RISC-V: enable rust

On Thu, Mar 30, 2023 at 11:12 AM Conor Dooley
<conor.dooley@...rochip.com> wrote:
>
> I'd rather do this in the RISC-V Makefile so that it does not get
> forgotten.

Sounds good to me! We want to have the least amount of things possible
in the common pieces (e.g. for the target spec file we moved some
flags); so the more we move out to `arch/`, the better.

> If my understanding of bindgen is correct, we don't actually need to be
> honest to it about what extensions the rest of the kernel is compiled
> with, only make sure that it is not called with arguments it does not
> understand?

As long as bindgen generates things with the right ABI etc., yeah.
But, in principle, enabling one extension one side but not the other
could be wrong if it ends up in something that Rust uses, e.g. if the
C side does:

    #ifdef __ARM_ARCH_7R__
        int x;
    #else
        char x;
    #endif

and Rust attempts to use it, then particular `-march` builds could be broken.

> Oh and clang-17 is going to support both of these, and Nathan and I
> already spent a bunch of time fixing the fallout from that!
> It still functions correctly without having them passed, but I have
> heard requiring these may become the default at some point too.
> What's done here may end up needing to be dynamic, but that bridge can be
> crossed if/when we come to it.
>
> What version of GCC do I need to replicate this? I can build tip-of-tree
> gcc if needs be.

Sorry, what do you want to replicate? If you mean what we had in the
old GitHub CI, I see:

    CONFIG_CC_VERSION_TEXT="riscv64-linux-gnu-gcc (Ubuntu
11.3.0-1ubuntu1~22.04) 11.3.0"

which successfully boots in QEMU for the kernel config we tested.

But if you are asking what should be supported, I guess it depends on
the RISC-V maintainers. Ideally, everything that the kernel supports
(GCC >= 5.1), but since the GCC+Rust builds are so experimental, I
think as long as something is tested from time to time, it would be
great (to at least know not everything is completely broken).

But if you think that would be too much effort to maintain, or even
GCC builds in general, then please feel free to ignore it for the time
being, i.e. it is better to have LLVM builds rather than nothing! :)

Cheers,
Miguel