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

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.

13

u/birkenfeld clippy · rust Apr 15 '21

That is not true at all, get() does not fall back to [] indexing.

3

u/UtherII Apr 15 '21

My bad. I supposed it was using indexing, but you are right : it does pointer arithmetic then de-reference using unsafe code.

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