Re: [TECH TOPIC] Rust for Linux

James Bottomley
2021-07-06T10:28:36Z

On Tue, 2021-07-06 at 07:30 +0300, Leon Romanovsky wrote:
> On Tue, Jul 06, 2021 at 01:51:11AM +0200, Linus Walleij wrote:
> > On Sat, Jun 26, 2021 at 12:09 AM Miguel Ojeda
> > <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> > > The Rust for Linux project is adding support for the Rust
> > > language to the Linux kernel. This talk describes the work done
> > > so far and also serves as an introduction for other kernel
> > > developers interested in using Rust in the kernel.
> >
> > I think this is a good tech topic.
>
> <...>
>
> > Demonstrate how the Rust code now elegantly avoid
> > ever seeing problems A,B,C again.
> >
> > From this it is very easy for the kernel community to deduce that
> > introducing Rust as an implementation language is worth it.
>
> I don't know about advantages of Rust, but from what I see there are
> some disadvantages that no one talks about them.

The main advantage is supposed to be "memory safety":

https://en.wikipedia.org/wiki/Memory_safety

But that's tempered by the fact that all non-rust code is deemed unsafe
and it's hard to write drivers without calling into the core, so
there's a lot of unsafe stuff going on even if you write your driver in
rust.

The other thing that makes comparison with C hard is the fact that
compilers and fuzzers are pretty good at detecting memory problems in
the existing code, so it's unclear what memory safety ab initio
actually buys for the kernel.

> 1. The addition of another language to the mix will hurt a lot our
> ability to refactor code for cross-subsystem changes.
>
> Just as an example, there are many changes in DMA/SG areas that are
> applicable for many drivers. Even simple grep->replace pattern will
> be harder and longer if it is needed for the drivers that are written
> in different languages.
>
> 2. Testing matrix will be duplicated, both in compilation tests and
> in verification coverage. Even now, there are some kernel subsystems
> that so much in-love with CONFIG_* options that their combination is
> slightly tested or not tested at all. So imagine, we will need to
> recompile everything with Rust too and execute same coverage tests
> again.

3. Less review: The lack of kernel programmers understanding rust
hampers reviewing. Since most of our CVE type problems are usually
programming mistakes nowadays, the lack of review could contribute to
an increase in programming fault type bugs which aren't forbidden by
the safer memory model.

James