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: <20230403-repose-cartwheel-c3e10c231cae@spud>
Date:   Mon, 3 Apr 2023 18:14:57 +0100
From:   Conor Dooley <conor@...nel.org>
To:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc:     Conor Dooley <conor.dooley@...rochip.com>,
        linux-riscv@...ts.infradead.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 Mon, Apr 03, 2023 at 06:35:45PM +0200, Miguel Ojeda wrote:
> 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.

To be on the safe side then, we should really disable the extensions
across the whole kernel. I don't *think* we have any madness at the
moment like in the above, but it is better to be on the safe side.
As I note below, it's just one extension for now anyway.

> > 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.

No, I misunderstood your question. I thought you meant something else
entirely.

> 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),

Heh, as if that number is true across the board!

> 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! :)

Yeah, it may be worth getting just the LLVM bits in. I abhor the -march
handling and it may end up looking like shite with the zicsr &
zifencei handling.
Worst comes to worst, can permit gcc builds by just removing all the
extensions that get passed in -march for RUST && CC_IS_GCC type
scenarios. The only one of those at the moment is zihintpause & I don't
suppose too many tears will be shed over that.
For now it's safe to assume that LLVM doesn't require zicsr or zifencei
[1], we don't need to do a version dance right away.

¯\_(ツ)_/¯,
Conor.

1 - https://reviews.llvm.org/D147183#4233360

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)