Re: Rust kernel policy

["Paul E. McKenney" <paulmck@kernel.org>]

On Wed, Feb 19, 2025 at 06:39:10AM +0100, Greg KH wrote:
> On Tue, Feb 18, 2025 at 07:04:59PM -0800, Boqun Feng wrote:
> > On Tue, Feb 18, 2025 at 04:58:27PM -0800, H. Peter Anvin wrote:
> > [...]
> > > > > David Howells did a patch set in 2018 (I believe) to clean up the C code in the kernel so it could be compiled with either C or C++; the patchset wasn't particularly big and mostly mechanical in nature, something that would be impossible with Rust. Even without moving away from the common subset of C and C++ we would immediately gain things like type safe linkage.
> > > > 
> > > > That is great, but that does not give you memory safety and everyone
> > > > would still need to learn C++.
> > > 
> > > The point is that C++ is a superset of C, and we would use a subset of C++
> > > that is more "C+"-style. That is, most changes would occur in header files,
> > > especially early on. Since the kernel uses a *lot* of inlines and macros,
> > > the improvements would still affect most of the *existing* kernel code,
> > > something you simply can't do with Rust.
> > > 
> > 
> > I don't think that's the point of introducing a new language, the
> > problem we are trying to resolve is when writing a driver or some kernel
> > component, due to the complexity, memory safety issues (and other
> > issues) are likely to happen. So using a language providing type safety
> > can help that. Replacing inlines and macros with neat template tricks is
> > not the point, at least from what I can tell, inlines and macros are not
> > the main source of bugs (or are they any source of bugs in production?).
> > Maybe you have an example?
> 
> As someone who has seen almost EVERY kernel bugfix and security issue
> for the past 15+ years (well hopefully all of them end up in the stable
> trees, we do miss some at times when maintainers/developers forget to
> mark them as bugfixes), and who sees EVERY kernel CVE issued, I think I
> can speak on this topic.
> 
> The majority of bugs (quantity, not quality/severity) we have are due to
> the stupid little corner cases in C that are totally gone in Rust.
> Things like simple overwrites of memory (not that rust can catch all of
> these by far), error path cleanups, forgetting to check error values,
> and use-after-free mistakes.  That's why I'm wanting to see Rust get
> into the kernel, these types of issues just go away, allowing developers
> and maintainers more time to focus on the REAL bugs that happen (i.e.
> logic issues, race conditions, etc.)
> 
> I'm all for moving our C codebase toward making these types of problems
> impossible to hit, the work that Kees and Gustavo and others are doing
> here is wonderful and totally needed, we have 30 million lines of C code
> that isn't going anywhere any year soon.  That's a worthy effort and is
> not going to stop and should not stop no matter what.
> 
> But for new code / drivers, writing them in rust where these types of
> bugs just can't happen (or happen much much less) is a win for all of
> us, why wouldn't we do this?  C++ isn't going to give us any of that any
> decade soon, and the C++ language committee issues seem to be pointing
> out that everyone better be abandoning that language as soon as possible
> if they wish to have any codebase that can be maintained for any length
> of time.

While not in any way pushing back on appropriate use of Rust in the Linux
kernel, it is only fair to note that the C++ folks have been working on
some safety proposals, perhaps most notably "contracts" and "profiles".
Not sure how well either would carry over to C, though.

							Thanx, Paul