linux-kernel - Re: [RFC 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]

Date:   Fri, 24 Feb 2023 15:18:03 -0800 (PST)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     miguel.ojeda.sandonis@...il.com
CC:     Conor Dooley <conor.dooley@...rochip.com>,
        linux-riscv@...ts.infradead.org, Conor Dooley <conor@...nel.org>,
        ojeda@...nel.org, alex.gaynor@...il.com, wedsonaf@...il.com,
        boqun.feng@...il.com, gary@...yguo.net, bjorn3_gh@...tonmail.com,
        corbet@....net, Paul Walmsley <paul.walmsley@...ive.com>,
        nathan@...nel.org, ndesaulniers@...gle.com, 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: [RFC 0/2] RISC-V: enable rust

On Fri, 24 Feb 2023 14:38:28 PST (-0800), miguel.ojeda.sandonis@...il.com wrote:
> On Fri, Feb 24, 2023 at 10:32 PM Palmer Dabbelt <palmer@...belt.com> wrote:
>>
>> I'm fine with it, but IIRC the Rust support for most targets was pulled
>> out as they weren't deemed ready to go yet.  If the Rust folks are OK
>
> So we trimmed the original series from v8 to v9 as much as possible in
> order to upstream things piece by piece, get maintainers involved, and
> so on; i.e. they were not trimmed because they were not ready.

OK, cool, that's way less scary.

> Having said that, for the architectures support in particular, what we
> had is indeed a prototype: each architecture we added was able to
> compile, boot into QEMU, load the sample Rust modules, pass a few
> tests, and so on in our CI, using a couple kernel configs. But that is
> just the basic support, and it does not mean it works for other kernel
> configs, all hardware, all security features, and so on.
>
> So it depends on how you want to approach it, whether you are
> interested in the basic support or not, etc. In any case, I would
> recommend having an expert on the architecture take a look to
> double-check things look sane, run some tests on real hardware, etc.

We generally take stuff pretty early in RISC-V land, for example we take 
a bunch of stuff that's just in the ISA but doesn't have any hardware 
yet.  The good news is that we don't really have any of the complicated 
language-tied features in RISC-V land, so with any luck it's pretty 
straight-forward to flip on.

>> turning on RISC-V support then it's fine with me, but I think it's
>> really more up to them at this point.
>>
>> So
>>
>> Acked-by: Palmer Dabbelt <palmer@...osinc.com>
>>
>> in case folks want to take it via some Rust-related tree, but I'm also
>> fine taking it via the RISC-V tree if that's easier.
>
> Thanks Palmer! We are trying to get maintainers of the different
> subsystems/archs/... involved so that they maintain the different Rust
> bits we are upstreaming, so ideally it would go through the RISC-V
> tree.

Works for me.

I've got a few other things in the pipeline for this merge window so 
this probably won't make it, but I'll dig in after that.  We've got a 
bunch of Rust-types floating around Rivos as well, so with any luck 
someone else will have some time to poke around.  Having a full cycle in 
linux-next is probably the right way to go for this sort of thing 
anyway, as it's likely to shake out some long-tail issues.

That'll also give us time to sort out the authorship issues, which we'd 
of course need to do before merging anything.