linux-kernel - Re: [PATCH v2 3/3] rust: Enable for MIPS

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: <54ce7574-43fd-40ee-9ae9-dd72283d1040@app.fastmail.com>
Date: Tue, 10 Sep 2024 20:10:21 +0100
From: "Jiaxun Yang" <jiaxun.yang@...goat.com>
To: "Maciej W. Rozycki" <macro@...am.me.uk>
Cc: "Masahiro Yamada" <masahiroy@...nel.org>,
 "Nathan Chancellor" <nathan@...nel.org>,
 "Nicolas Schier" <nicolas@...sle.eu>,
 "Richard Weinberger" <richard@....at>,
 "Anton Ivanov" <anton.ivanov@...bridgegreys.com>,
 "Johannes Berg" <johannes@...solutions.net>,
 "Thomas Gleixner" <tglx@...utronix.de>, "Ingo Molnar" <mingo@...hat.com>,
 "Borislav Petkov" <bp@...en8.de>,
 "Dave Hansen" <dave.hansen@...ux.intel.com>, x86@...nel.org,
 "H. Peter Anvin" <hpa@...or.com>, "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>,
 "Benno Lossin" <benno.lossin@...ton.me>,
 "Andreas Hindborg" <a.hindborg@...sung.com>,
 "Alice Ryhl" <aliceryhl@...gle.com>,
 "Thomas Bogendoerfer" <tsbogend@...ha.franken.de>,
 "Steven Rostedt" <rostedt@...dmis.org>,
 "Masami Hiramatsu" <mhiramat@...nel.org>,
 "Mark Rutland" <mark.rutland@....com>,
 "Jonathan Corbet" <corbet@....net>, "Alex Shi" <alexs@...nel.org>,
 "Yanteng Si" <siyanteng@...ngson.cn>,
 "Nick Desaulniers" <ndesaulniers@...gle.com>,
 "Bill Wendling" <morbo@...gle.com>,
 "Justin Stitt" <justinstitt@...gle.com>, linux-kbuild@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-um@...ts.infradead.org,
 rust-for-linux@...r.kernel.org,
 "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
 linux-trace-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
 llvm@...ts.linux.dev
Subject: Re: [PATCH v2 3/3] rust: Enable for MIPS

在2024年9月10日九月 下午5:03，Maciej W. Rozycki写道：
> On Mon, 9 Sep 2024, Jiaxun Yang wrote:
>

>> >  What's the consequence of using `mips2' rather than `mips1' here?  How 
>> > about other ISA revisions, e.g. `mips4' (that also applies to the 64BIT 
>> > leg)?
>> 
>> LLVM's mips1 backend is a little bit broken beyond repair, so I tried to use mips2
>> as a baseline. I should probably let HAVE_RUST depend on !CPU_R3000 to get it covered.
>
>  GCC works just fine I suppose, just as with the other language frontends, 
> doesn't it?

Nah, currently we can only use rustc with LLVM backend. target.json file
we are generating here is also LLVM backend only for rustc.

gccrs is not usable for kernel yet.

>
>> We have no good way to tell ISA reversion prior to R1 just from Kconfig TARGET_ISA_REV,
>> valid numbers for TARGET_ISA_REV are only 1, 2, 5, 6 from Kconfig.
>
>  This approach doesn't work for some MIPS architecture processor configs 
> anyway, e.g. what ISA revision will CPU_P5600 imply here?

TARGET_ISA_REV will be set to 5 for CPU_P5600 (CPU_MIPSR5 will default to y
on CPU_P5600, and CPU_MIPSR5 sets TARGET_ISA_REV to 5). 
>
>  However if there's a need (and previously there wasn't), then I think it 
> can be sorted in a straightforward way.  We have just a bunch of CPU_* 
> settings and we can define corresponding ISA_* settings to select, e.g. 
> ISA_MIPS1, ISA_MIPS3, ISA_MIPS32_R1, ISA_MIPS64_R6, and so on, based on 
> information extracted from per-CPU_* `-march=' compilation flags from 
> arch/mips/Makefile (possibly combined with ISA data obtained from 
> GCC/binutils for said flags).
>
>  It could be a bit tedious to write, but not a big challenge really, just 
> mechanical work.

TARGET_ISA_REV is guaranteed to be aligned with CPU's supported ISA for now,
so I see no reason to invent another set of symbols....

>
>> Given that mips 2 and 3 binaries (Rust object files) can link run flawlessly on all pre-R6
>> (despite R3000) hardware with matching bitness, they were chosen as fallback here.
>
>  I'm fine with having a MIPS1/R3000 exception for broken LLVM, but I see 
> no reason to disable it for GCC.

It actually reminds me that LLVM lacks R4000 and some other workarounds as well.
I shall fix those in Kconfig as well.

Thanks

>
>   Maciej

-- 
- Jiaxun