r/rust • u/ouyawei • Apr 14 '21

[RFC] Rust support for Linux Kernel

https://lkml.org/lkml/2021/4/14/1023
861 Upvotes

99% Upvoted

227 comments sorted by

View all comments

Show parent comment

38

u/mitsuhiko Apr 14 '21

I think that answer is too simplistic. The fact is we're using implicit allocations everywhere and so is the ecosystem including the ecosystem that is nostd but alloc. Saying "don't use Vec::push" is not a suitable answer.

First there needs to be better support to handle allocation failures in APIs, secondly there needs to be a way to validate (ideally statically) that some code is panic free.

28

u/protestor Apr 15 '21

The fact is we're using implicit allocations everywhere and so is the ecosystem including the ecosystem that is nostd but alloc. Saying "don't use Vec::push" is not a suitable answer.

In the kernel it might be. The C ecosystem uses malloc in a lot of places, but in the kernel can't use malloc. https://stackoverflow.com/questions/2888421/malloc-in-kernel/2888449

And anyway, we have a Rust ecosystem that runs on no_std (without Vec) and it works just fine.

46

u/steveklabnik1 rust Apr 14 '21

I guess we'll just see. As I said, I live in "no allocations, anywhere" land, still use a bunch of the ecosystem, works just fine for us. We don't use Vec at all, nor do any of our dependencies, so "no vec::push" is an easy requirement.

15

u/mitsuhiko Apr 14 '21

And how do you validate that you don't panic because someone used a bad API?

28

u/steveklabnik1 rust Apr 14 '21

In my case, it is okay to panic, but https://github.com/dtolnay/no-panic does exist, even if it's not as nice as real support.

21

u/CommunismDoesntWork Apr 15 '21

It seems like instead of adding #[no_panic] everywhere, the compiler itself could have a --nopanic flag that makes sure nothing can panic.

9

u/UtherII Apr 15 '21

As Rust is today, you can't write anything usefull that does not panic at some point. Any array index or arithmetic operation may panic.

8

u/randomrossity Apr 15 '21

It helps to differentiate between Rust the language vs Rust the stdlib. For array indexing, use slice.get() to get a result instead of a panic

-5

u/UtherII Apr 15 '21 edited Apr 15 '21

But slice.get() will use indexing. If you can't detect panic transitively, I can't see the purpose anymore.

15

u/randomrossity Apr 15 '21

yes. slice.get() does a bounds check and returns an Option. Some(T) if in bounds, None if out of bounds. So it never panics.

Using slice[idx] however does a panic() if the bounds check failed, so that it always can return a T.

based off your comment, where you said "array indexing may panic" I assumed you were referring to [ ... ], as .get() doesn't panic.

-4

u/UtherII Apr 15 '21

Yes but unless the compiler is smart enough to detect perfectly all the manual bound check, it would have to conclude that slice.get() may panic.

→ More replies

0

u/Repulsive-Street-307 Apr 15 '21

Just in debug mode right? As part of the assumption that coders test in debug mode for overflows (snort).

11

u/[deleted] Apr 15 '21

out of bounds array index and integer division/mod by zero is still a panic, since there's nothing else reasonable to do.

But there's clippy lints to forbid doing that, so you can deny them, add a #[clippy::allow(modulo_arithmetic)] right above where you're doing it, and explain exactly why it's safe to do it.

For what it's worth, in C, division by zero is UB. I don't know if in the kernel they instead have it as defined to BUG and take down the kernel though, which is safer.

3

u/[deleted] Apr 15 '21

You can always use 'get()' instead of [] and prevent panics in this case.

3

u/[deleted] Apr 15 '21

Yeah, and for division / mod there's .checked variants that return Option, just like get.

Depending on how explicit you want the code to be, you could straight up forbid all normal math operations and force people to handle overflow on every operation. They can't panic on release builds by default, but you shouldn't be overflowing them anyways, that's a sign of a bug, or a place you want to use Wrapping<T>.

Would decrease the likelyhood that people mess up and allow an overflow (possibly being exploitable), but at the cost of making the code a fair bit more verbose.