Re: [TECH TOPIC] Rust for Linux

[Marco Elver <elver@google.com>]

On Tue, Jul 06, 2021 at 04:55PM +0200, Miguel Ojeda wrote:
> 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
[...]
> > 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).

I think the main point was about the combination of sanitizers paired
with fuzzers like syzkaller.

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

I sincerely hope that not too much trust will be put into Rust-only
dynamic analysis via something like Miri (for the unsafe parts). For the
kernel, first and foremost, the Rust integration will require proper
integration with existing sanitizers (with `rustc -Zsanitizer=`??):
KASAN, KCSAN (possibly KMSAN which is still out-of-tree).

We have years of experience with kernel dynamic analysis, and discover
over and over that bugs are missed due to uninstrumented code paths
(including inline asm and such), and put in a lot of effort to
instrument as much as possible.

It is very likely that if the Rust portion is analyzed alone, be it
statically or dynamically, that there will remain undiscovered bugs due
to improper abstractions between C and Rust. While I fully see that
Rust's static guarantees are strong for safe code, I'm pragmatic and
just do not believe those building the safe abstractions from unsafe
code will not make mistakes nor will those abstractions shield from
changed behaviour on the C side that directly affects safety of the Rust
abstraction.

Not only will Rust integration with K*SANs be required to catch early
bugs in the abstractions, but also be necessary to catch e.g.
use-after-frees in Rust code where C code freed the memory erroneously,
or data races between Rust and C code.

But it will ultimately also prove that the main proposition of Rust in
the kernel holds: less bugs in the Rust parts over time.