linux-kernel - Re: Rust kernel policy

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: <CAPM=9tyWvKcUnP2XJh5G=4nSCjum69phxNpOG8adPunQ+3TNdA@mail.gmail.com>
Date: Wed, 19 Feb 2025 08:38:29 +1000
From: Dave Airlie <airlied@...il.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, Christoph Hellwig <hch@...radead.org>, 
	rust-for-linux <rust-for-linux@...r.kernel.org>, 
	Linus Torvalds <torvalds@...ux-foundation.org>, Greg KH <gregkh@...uxfoundation.org>, 
	linux-kernel@...r.kernel.org, ksummit@...ts.linux.dev
Subject: Re: Rust kernel policy

> I have a few issues with Rust in the kernel:
>
> 1. It seems to be held to a *completely* different and much lower standard than the C code as far as stability. For C code we typically require that it can compile with a 10-year-old version of gcc, but from what I have seen there have been cases where Rust level code required not the latest bleeding edge compiler, not even a release version.
>

This is a maturity thing, as the rust code matures and distros start
shipping things written in rust, this requirement will tighten in, as
long as there is little rust code in the kernel that anyone cares
about why would they want to lock down to a few years old compiler,
when nobody is asking for that except people who aren't writing rust
code at all. It will happen, there is already a baseline rust
compiler, again until there is enough code in the kernel that bumping
the compiler for new features is an impediment it should be fine, but
at the point where everyone is trying to stop rust from maturing, this
talking point is kinda not well thought through.

> 2. Does Rust even support all the targets for Linux?

Does it need to *yet*? This might be a blocker as rust moves into the
core kernel, but we aren't there yet, it's all just bindings to the
core kernel, yes eventually that hurdle has to be jumped, but it isn't
yet, I also suspect if we rewrite a major core piece of kernel, it
will coexist with the C implementation for a short while, and maybe
that will help us make decisions around the value of all the targets
we support vs the effort. Again this is a maturity problem down the
line, it isn't a problem right now. It's also a good chance gcc-rs
project will mature enough to make the point moot in the meantime.

>
> 3. I still feel that we should consider whether it would make sense to compile the *entire* kernel with a C++ compiler. I know there is a huge amount of hatred against C++, and I agree with a lot of it – *but* I feel that the last few C++ releases (C++14 at a minimum to be specific, with C++17 a strong want) actually resolved what I personally consider to have been the worst problems.
>
> As far as I understand, Rust-style memory safety is being worked on for C++; I don't know if that will require changes to the core language or if it is implementable in library code.

No it isn't, C++ has not had any rust-style memory safety topics
manage to get anywhere, C++ is just not moving here, Sean Baxter
(circle compiler developer) has proposed safety extensions and has
been turned away. Yes templates would be useful, but maintaining a
block on all the pieces of C++ that aren't useful is hard, I'm not
even sure expert C++ programmers will spot all of that, again Linus
has show no inclination towards C++ so I think you can call it a dead
end.

Dave.