Re: [TECH TOPIC] Rust for Linux

[Kees Cook <keescook@chromium.org>]

On Thu, Jul 08, 2021 at 09:49:15PM +0200, Linus Walleij wrote:
> My concern is still whether this really brings Rust closer to the actual
> problems we have and that Rust can solve. If the problem is really
> about real world security issues, I would ask Kees where the actual
> attack surface of the kernel is. He knows.

Oh yes indeed! Two big classes of flaws the kernel suffers from due
to being written in C are buffer overflows and use after free. Both
of these are strongly mitigated by Rust's borrow checking. The other
class I've been concerned with is arithmetic overflow (which usually
precedes a buffer overflow), and that's why I've been pushing for the
kernel's Rust to operate in Rust's "trap on overflow" mode by default,
where the exceptions that expect a wrap-around use a distinct API.

> It kind of matters. EternalBlue (WannaCry) was a horrific Windows
> exploit in that it shows us pretty well what kind of cyberweapons the
> intelligence agencies of the world have been constructing and
> stockpiling, and probably also used. We need to put countermeasures
> where such exploits are likely to hit, yesterday. Intuitively I would
> say any in-kernel network daemons, anything complex that
> responds directly to network traffic, is a good thing to fix. I do not

FWIW, wireless drivers have been a persistent source of buffer overflows.

I've been working on some changes to our memcpy() use in the kernel to
help address this, but it's not quite finished yet. Very soon, I hope!
But even these changes are just dealing with the "easy" cases where
the code is luckily enough arranged in a way that the compiler can do
the bounds checking. (The same goes for CONFIG_UBSAN_BOUNDS.) Rust just
makes the whole class of problem go away because of its borrow semantics.

-Kees

-- 
Kees Cook