Re: [TECH TOPIC] Rust for Linux

[Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>]

On Tue, Jul 6, 2021 at 12:20 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> The main advantage is supposed to be "memory safety":
>
> https://en.wikipedia.org/wiki/Memory_safety

Yes, although please note it covers other things, like data races.

In general, Rust prevents the kind of thing that is UB in C, which
means it also covers you from the usual surprises that optimizers may
give you.

> 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.

Yes, but bugs on the C side are still bugs, and they need to be fixed
regardless of Rust.

That is to say: the fact that the C side has bugs does not mean Rust
is pointless in the kernel. The value is to write drivers with a
safe-as-possible API. By doing that, we avoid extra bugs (but, of
course, bugs on the unsafe Rust code or in the C side remain can still
happen).

> 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.

Compilers definitely do not detect all memory safety issues -- not
even close. They cannot anyway, in the general case. Not even in C++
with `std::unique_ptr`, `std::vector`, etc. Rust can do so because it
places extra restrictions in the modeling capabilities (in the safe
subset only).

Runtime detection of UB in C is, of course, possible, but the idea is
to have static guarantees vs. runtime-checked ones. There is also
runtime detection of UB in Rust for unsafe code with tooling like
Miri. plus all the language-independent tooling, of course.

> 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.

Yes, this is a fair point. Initially, our plan is to work with
subsystem maintainers that do want to start providing a Rust API for
their subsystem. Then they can maintain drivers using such API.

We definitely do not want to have drivers written for a particular
subsystem if nobody is able to review (or even write) the Rust
abstractions for that particular subsystem.

Cheers,
Miguel