The Latest Progress On Rust For The Linux Kernel

[mdedetrich]

Then don't use RefCells in your code, it is as simple as that.

Indeed, there are even tools that can statically analysis your code to determine these EXPLICIT, and this is deliberately bolded because it appears, either intentional or not, that people aren't distinguishing the difference (either that or they don't know what abstractions/types are in which case they shouldn't even be arguing about this).

https://crates.io/crates/cargo-geiger is an example of such a tool for unsafe, although doing the same with RefCell is kind of pedantic and pointless because if Rust programmers are using RefCell they know there is an addition runtime cost (in the exact same way if you use virtual in C++ you know there is a runtime cost since you are creating a vtable).

I mean whats next, you are going to start claiming that C isn't a zero cost language because the Linux kernel implemented a vtable (which obviously incurs a runtime cost).

I wasn't talking about memory management only, you both are still stuck in your discussion with cl333r. I meant in Rust in general. Allocation failures are a good example as oleid said a little bit earlier, but there are also bounds checking and arithmetic (under-/overflow, downcasting) checks. I know these can be disabled, but then they also don't provide their advantages anymore.

Uh yes they do, almost all of the security/memory related issues are due to under/overflow/range checks not being done.

The Rust compiler may internally validate within your program that an under/over flow doesn't happen, but if you are accepting input from the outside world then its possible for someone else to construct an input that causes an under/overflow.

Thats why they are enabled by default, because literally this is the biggest cause of CVE's in C/C++. This is why Java has enforced boundary checks on things like Array's and because of this, at least this class of security problems basically don't exist in Java unless you are really trying hard to bypass it.

You can for example "disable" some of these checks in Rust by putting in things like assert, because then the compiler can see that the program will crash before such an over/under flow can happen (see https://doc.rust-lang.org/std/macro.assert.html#uses)

[ultimA]

Indeed, there are even tools that can statically analysis your code to determine these EXPLICIT, and this is deliberately bolded because it appears, either intentional or not, that people aren't distinguishing the difference (either that or they don't know what abstractions/types are in which case they shouldn't even be arguing about this).

https://crates.io/crates/cargo-geiger is an example of such a tool for unsafe, although doing the same with RefCell is kind of pedantic and pointless because if Rust programmers are using RefCell they know there is an addition runtime cost (in the exact same way if you use virtual in C++ you know there is a runtime cost since you are creating a vtable).

I mean whats next, you are going to start claiming that C isn't a zero cost language because the Linux kernel implemented a vtable (which obviously incurs a runtime cost).

You are not paying attention. First, I repeat, I said nothing about RefCell. Second, and most importantly, this isn't about being zero-cost at all (or about comparing costs with C). It is you who is talking about overheads and the performance-aspect, we didn't criticize that in any way. The discussion was originally to point out that Rust's abort-if-my-soundness-rules-are-violated is actually pretty crap in many software projects, and all safety-critical projects (not in Rust's sense of safety, but in actual safety). Cool, the abort-on-allocation-failure is being disabled for the kernel. Fine, this is a minimum requirement. What about all the other checks, and what about all the other projects? Rust's security model is just not right for many projects. For many others of course, it is exactly what people want. But advocates tend to forget about one half.

[mdedetrich]

You are not paying attention. First, I repeat, I said nothing about RefCell. Second, and most importantly, this isn't about being zero-cost at all (or about comparing costs with C). The discussion was originally to point out that Rust's abort-if-my-soundness-rules-are-violated is actually pretty crap in many software projects, and all safety-critical projects (not in Rust's sense of safety, but in actual safety). Cool, the abort-on-allocation-failure is being disabled for the kernel. Fine, this is a minimum requirement. What about all the other checks, and what about all the other projects? Rust's security model is just not right for many projects. For many others of course, it is exactly what people want. But advocates tend to forget about one half.

This is also wrong, because as has been stated some of the mentioned checks are part of the stdlib which the kernel is not going to be using anyways and others are configurable. Thats what being explicit means, you have to actually opt to use them and the Kernel is not going to be using the abstractions you are talking about, and if not you can also configure them otherwise (in the cases where you have to configure it, its typically not to do with performance but rather panicking when the program is in some undesired state).

It was brought up by Linus at https://lkml.org/lkml/2021/4/14/1099 but it turns out you can configure to not do the behavior Linus is talking so its a non concern, this is not some hardcoded design in Rustc, you can actually configure it https://ddanilov.me/panic-in-rust.

This behavior is just the default because when it comes to applications/libraries in userspace, panicking is the best thing to do in these situations (as a default). Of course for the kernel its not but its not a big deal. There are a couple of cases where some additions need to be done in Rust (as noted in the reply https://lkml.org/lkml/2021/4/14/1130) but as he said its nothing fundamental so frankly this is getting to the point of concern trolling right now.

[oleid]

I said nothing about RefCells...

Well, you talked about random crashes at runtime due to a borrow checker seeing something.
Apart from what is usually referred to "the borrow checker" being a compile-time thing, the only thing which is related and run-time is the RefCell.
What else did you have in mind?

[ultimA]

This is also wrong, because as has been stated some of the mentioned checks are part of the stdlib which the kernel is not going to be using anyways and others are configurable. Thats what being explicit means, you have to actually opt to use them and the Kernel is not going to be using the abstractions you are talking about, and if not you can also configure them otherwise (in the cases where you have to configure it, its typically not to do with performance but rather panicking when the program is in some undesired state).

It was brought up by Linus at https://lkml.org/lkml/2021/4/14/1099 but it turns out you can configure to not do the behavior Linus is talking so its a non concern, this is not some hardcoded design in Rustc, you can actually configure it https://ddanilov.me/panic-in-rust.

This behavior is just the default because when it comes to applications/libraries in userspace, panicking is the best thing to do in these situations (as a default). Of course for the kernel its not but its not a big deal. There are a couple of cases where some additions need to be done in Rust (as noted in the reply https://lkml.org/lkml/2021/4/14/1130) but as he said its nothing fundamental so frankly this is getting to the point of concern trolling right now.

So if the kernel developers say it needs changing, and the Rust developers agree it needs changing, and someone points this out on the forums, then it is trolling? What kind of logic is that?

And no, it is hardcoded and not configurable, at least not the way you are showing/linking it. That configuration option only allows you to switch from panicing to aborting, but in fact both have the same fundamental problem of terminating upon violating a condition. I know what you are going to say: "Panic only terminates the current thread!" Yes, but this blithely ignores the fact that most programs are single-threaded, so for most programs, this is still essentially the same as crashing the program.

[oleid]

but there are also bounds checking [...]. I know these can be disabled, but then they also don't provide their advantages anymore.

How do you feel about using .at(index) for vectors in C++?

[ultimA]

Well, you talked about random crashes at runtime due to a borrow checker seeing something.
Apart from what is usually referred to "the borrow checker" being a compile-time thing, the only thing which is related and run-time is the RefCell.
What else did you have in mind?

Nope, I talked about crashing at runtime, but not in connection with the borrow checker. You are mixing up my posts with cl333r's. Actually, my first post in this thread was pointing out that cl333r was wrong in bringing the borrow checker as an example for runtime checks.

[oleid]

Nope, I talked about crashing at runtime, but not in connection with the borrow checker. You are mixing up my posts with cl333r's. Actually, my first post in this thread was pointing out that cl333r was wrong in bringing the borrow checker as an example for runtime checks.

Right, it was misleadingly cited in your posting I quoted.

Anyway, most things that may result in a panic have a "try_" variant in the standard library nowadays. I would assume that the other ones will get deprecated in a future edition.

[mdedetrich]

So if the kernel developers say it needs changing, and the Rust developers agree it needs changing, and someone points this out on the forums, then it is trolling? What kind of logic is that?

That is the literal definition of concern trolling, which is making a "concern" out of something thats already been recognized and its a non issue at this point so why are you even bringing it up

And no, it is hardcoded and not configurable, at least not the way you are showing/linking it. That configuration option only allows you to switch from panicing to aborting, but in fact both have the same fundamental problem of terminating upon violating a condition. I know what you are going to say: "Panic only terminates the current thread!" Yes, but this blithely ignores the fact that most programs are single-threaded, so for most programs, this is still essentially the same as crashing the program.

Some things are, some things are not, it depends on what we are talking about. For the things that aren't as pointed out a lot a lot of the adjustments have already been made. The only real issue is math overflow, which is ironically something that Rust copied over from C (which I disagree with). Even someone from the kernel maintainers pointed this out at https://lkml.org/lkml/2021/4/14/1311 (i.e. he wished that Rust was actually more strict than C here and established some standard on how to handle math overflow because this is a common problem that occurs in C and apparently in the kernel)

But again why are you bringing this up, we were talking about borrow checking which is completely different topic.

[ultimA]

That is the literal definition of concern trolling, which is making a "concern" out of something thats already been recognized and its a non issue at this point so why are you even bringing it up

It will only become a non-issue when it finally gets addressed and a "fix" is available, not when people admit it is an issue.
Also, you've got the definition of "concern trolling" completely wrong.

But again why are you bringing this up, we were talking about borrow checking which is completely different topic.

Because this is where the discussion originally started. It's not my fault you went off-topic for 10+ pages discussing with someone else whether the borrow-checker has runtime checks or not. I don't feel any need to continue that discussion. Do you? Especially since you and I agree on that topic.