Re: [TECH TOPIC] Rust for Linux

[Linus Walleij <linus.walleij@linaro.org>]

On Mon, Jul 19, 2021 at 4:42 PM Wedson Almeida Filho
<wedsonaf@google.com> wrote:

> > I think people want to see the code inside these classes as well,
> > can we browse it?
>
> The whole tree is available here: https://github.com/wedsonaf/linux/tree/pl061
> -- I should caution you that the two most recent commits are not merged into the
> rust tree yet because they're WIP. (I'll clean them up and eventually merge
> after the feedback from you all.)

I found that the gpio_chip C wrappers lives here:
https://github.com/wedsonaf/linux/blob/pl061/rust/kernel/gpio.rs

This file is very interesting!

I think it's not a good idea to keep these wrappers in their own
rust directory, they need to be distributed out into the kernel
everywhere they are used. We have made this mistake before
with OF (device tree) that started exactly like this in
drivers/of/*, and now I have part of the OF GPIO handling
and tests inside files in that directory as a consequence.

The wrappers are a hard read, I notice a whole lot of unsafe
keywords here, Chip is missing .set_config() which is understandable
since PL061 isn't using it, the New call to create an instance
contains a lot of magic stuff I don't understand like
state: AtomicU8::new(0) and such but I think that's all right
it probably only needs a trained eye.

This binding only concerns the gpio_chip abstraction though,
which means that the struct gpio_device and the creation and
handling of the GPIO character device, all of the ioctl()
and passed in/out data from userspace is left in C in gpiolib.c

I think this is the current ambition of the Rust effort for now,
which is fine, one can not be judged for doing what one
attempts to do.

But we need to acknowledge that by leaving the userspace
facing code in C the attack surface for buffer overruns
etc is left in C and it buys us pretty much zero additional
security. And with security I do not mean the kernel
protecting itself from itself, but from things coming from
userspace.

It's not that I think GPIOs are an especially interesting
attack vector, but if this pattern persists then it becomes
a problem, because Rust isn't yet protecting us (GPIO)
against userspace, which is what it needs to do in the end.

What we get now is the ability to write drivers in Rust,
but no protection against a hostile userspace. Not really.

To that end the core of the GPIO library would probably
have to be rewritten in Rust and used on *all* platforms
in order to buy us any improved security. I understand that
this is not currently the plan.

This is what I have said before as well: Rust needs to go
where the attack surface of the kernel is to buy us any
real security. But getting there will require rewriting entire
subsystems in Rust AFAICT.

Yours,
Linus Walleij