Latest Patches Sent Out For Adding Rust Support To The Linux Kernel

[ultimA]

Oh, you just assume those bugs are in rust code, but you actually don't know...

I just explained in the post that you answered to what the reasoning is, why it must be. And no, those other "possible" reasons you name cannot be because:

Well, another explanation might be: the tools got better and there are more reports for the C++ code parts.

So it just happens by chance, that the tools found exactly that much more issues as the amount of code that was rewritten? While not impossible, but highly unlikely. This would be a very big coincidence and certainly big enough to now need proof on your part that this is indeed what's happened.

Or: the other code parts didn't generate many CVEs before and the amout of CVEs simply grow because the total LOC grew.

Not the case because I wasn't talking in absolute amounts of code or number of CVEs, but percentages. This would only be possible if only the C++ parts grew in LOC, or at least grew a lot faster than Rust parts, which would contradict the project's overall goal to replace C++ parts with Rust.

Please come back with solid claims on rust in Firefox without any dubious statistical FUD.

But so far you have failed to provide any other viable explanations. Not FUD until you do so. Also it is fun that CVE statistics are exactly what people refer to to prove how memory-unsafe C++ is, but when the same thing is done with Rust, you dismiss it by saying these are just dubious statistics. No, it's the same statistics that proponents of Rust used themselves except this time we have empirical evidence and not just assumptions about future statistics.

[ssokolow]

Why would you guess that? There are always unstable features in the stable and beta channels, why would you assume they're also pulling in some more?

Because, by design, you either need to use the nightly compiler to use unstable language features or abuse the environment variable for building new versions of rustc. Claiming "this builds on stable but uses unstable language features" implies the latter.

[oleid]

Also it is fun that CVE statistics are exactly what people refer to to prove how memory-unsafe C++ is, but when the same thing is done with Rust, you dismiss it by saying these are just dubious statistics. No, it's the same statistics that proponents of Rust used themselves except this time we have empirical evidence and not just assumptions about future statistics.

1. You didn't provide rust CVEs for firefox, just some statistics. I checked a few CVEs and they are all in C++ code. So no, guesstimating doesn't help. Provide me at least one about rust code which is about memory unsafety. Or at least one about rust code, if you don't find any with memory unsafety.
2. Not all CVEs are about memory unsafety. But in C++ most are according to the stats you quoted.
3. The rust CVEs about the packages on crates.io are not about memory unsafety. Those are bad bugs fore sure, but not about memory unsafety. That is something entirely different.
4. I don't argue that there are no bugs in firefox's rust code. And I'm positive you'll find crashes in rust code. Or maybe even CVEs where some parser did something stupid. But I'm positive you find none about memory unsafety. And that was all that was ever promised.

[Alexmitter]

Oh please don't add fucking cargo as a kernel dependency. Rust, ok if it helps, but cargo is literally the definition of distro-unfriendly software.

If you already think cargo is bad, then you will be surprised when LLVM becomes a kernel dependency.

Lets see how powerful Google has become in the linux space, if they are able to force the LLVM trash onto us then they already won.

[oleid]

If you already think cargo is bad, then you will be surprised when LLVM becomes a kernel dependency.

If we are lucky, by the time rust is needed for building the kernel, we have a gcc based rust implementation.

[NobodyXu]

Imho there are several issues with rust:
- It's much less popular than c. This means even more difficult to find good maintainers. (without maintainers code probably gonna be quickly removed)
- For example in case of c++ language, developers who know c can extract parts which they don't understand and check them on cppreference.com This doesn't work with rust. (I agree that using directly all of c++ isn't also good option for kernel)
- (personal opinion) Rust and stuff around rust isn't mature (enough) yet. Project in which you can quickly put hotfixes - yes, large codebase with relatively slow release cycle - no,

About the second point, I would sat it is the complete opposite.

c++ as a language is much more complex than c or rust and checking cppreference alone would take you a lot of time.

For example, there are at least 3 ways (4 in c++20) to initialize objects and the list initialization is really similar to initializer list initialization.

Move semantics, is also a problem since it doesn’t specify whether an object is still valid and can be reused after another object moved from it and it requires additional attention of the code reviewers to ensure that it is not misused.

Template is another complex language structure of C++ and often responsible for generating unreadable compile tome error.

It isn’t until C++20 do we get concept checking support in the language level, and guess what, we instantly got another gotcha https://quuxplusone.github.io/blog/2...s-chest-mimic/

Even without this gotcha, c++20 has not yet gained full support from gcc and clang.

[ultimA]

[LIST=1][*]You didn't provide rust CVEs for firefox, just some statistics. I checked a few CVEs and they are all in C++ code. So no, guesstimating doesn't help. Provide me at least one about rust code which is about memory unsafety. Or at least one about rust code, if you don't find any with memory unsafety.

As you command, my lord. CVE-2021-23987. Purely rust, memory corruption.
Too bad you didn't check all. You cannot just check a small portion of something and expect that your observings are valid for the whole lot greater whole. Who's guesstimating now?

Not all CVEs are about memory unsafety. But in C++ most are according to the stats you quoted.

I never said all CVEs are memory unsafety. I'm talking about specifically those CVEs that are memory unsafety. And as clearly shown by the statistics, code which has a lot of Rust doesn't necessarily has less memory-unsafety issues at all.

The rust CVEs about the packages on crates.io are not about memory unsafety. Those are bad bugs fore sure, but not about memory unsafety. That is something entirely different.

What? I'm sorry to call this out loud but now you're just BS. That list is mostly about memory issues. "out-of-bounds write", "double-drop". "drop of uninitialized memory", "sensitive information from uninitialized memory", "memory corruption", "use-after-free", "NULL pointer dereference". Many-many of each type. How come any of these are not about memory safety? And surprisingly, while many of them are, a significant portion is not even in unsafe code. You can check for yourself, I did.

I don't argue that there are no bugs in firefox's rust code. And I'm positive you'll find crashes in rust code. Or maybe even CVEs where some parser did something stupid. But I'm positive you find none about memory unsafety. And that was all that was ever promised.

As seen above, you've been proven wrong about this. Rust code can and will have memory issues too, even a significant amount, as CVE reports, real-life codebases, and statistical evidence all show. Over my past couple of posts, I've provided examples for each. You keep repeating about how sure you are in Rusts memory safety, but this is now clearly based on pure belief, ignoring the numerous counterexamples in the wild.

[oleid]

As you command, my lord. CVE-2021-23987. Purely rust, memory corruption.
Too bad you didn't check all. You cannot just check a small portion of something and expect that your observings are valid for the whole lot greater whole. Who's guesstimating now?

Well, you claimed something and didn't back it up.

The linked bug reports is https://bugzilla.mozilla.org/show_bug.cgi?id=1690718

It says: "Potential crash when an audio stream stops."

The problem is that they didn't wait for all clients to disconnect before stopping a server.
Classic logic error.

What? I'm sorry to call this out loud but now you're just BS. That list is mostly about memory issues. "out-of-bounds write", "double-drop". "drop of uninitialized memory", "sensitive information from uninitialized memory", "memory corruption", "use-after-free", "NULL pointer dereference". Many-many of each type.

• If you do an "out of bounds" write in a vector in rust, it will crash the program. The std library makes sure of that. If your code produces out-of-bounds, it will compile, but not run. In c++ those will get unnoticed if you use [], but will be caught if you use at().
  So yes, you can program those "out-of-bounds", but it is a logic error, no unsafety, as the oob is caught at run time.
• same goes for double drop; It is a huge difference if your program will be terminated in case of such bugs or silently go on.
• uninitialized memory you can only get from within unsafe code. Yes, you can write memory safety bugs in unsafe code.
• same goes for memory corruption
• use after free is prevented in safe code at compile time
• null pointer de-reference can also only happen in usafe code

Nobody said you cannot program safety bugs in usafe code, I'm sorry.

As seen above, you've been proven wrong about this. Rust code can and will have memory issues too, even a significant amount, as CVE reports, real-life codebases, and statistical evidence all show.

See above. Nobody claimed that you cannot program unsafe code in unsafe environments. Some pages ago, people said those bugs will happen at the C/interop layer.
Other people think they need unsafe code in their crate to do something fast. But usually this is not required.
There are even tools which list if your dependencies use unsafe code at all.

Over my past couple of posts, I've provided examples for each. You keep repeating about how sure you are in Rusts memory safety, but this is now clearly based on pure belief, ignoring the numerous counterexamples in the wild.

Again, you can do many things in unsafe code, which will break safety guarantees. In safe code, if you access a vector "out of bounds" your program will panic (at the moment). This is also a way to prevent unsafety - as a last resort. If this is not acceptable, you can use the getters, which check bounds and provide an optional reference.



The bottom line is: when using rust, stick to safe code as much as possible.

[ultimA]

Well, you claimed something and didn't back it up.

The linked bug reports is https://bugzilla.mozilla.org/show_bug.cgi?id=1690718

It says: "Potential crash when an audio stream stops."

The CVE summary states it is a memory corruption bug. How it comes to be is irrelevant.

• If you do an "out of bounds" write in a vector in rust, it will crash the program. The std library makes sure of that. If your code produces out-of-bounds, it will compile, but not run. In c++ those will get unnoticed if you use [], but will be caught if you use at().
• So yes, you can program those "out-of-bounds", but it is a logic error, no unsafety, as the oob is caught at run time.
• same goes for double drop; It is a huge difference if your program will be terminated in case of such bugs or silently go on.

Not being able to continue execution at the same time makes Rust unsuited for critical infrastructure categorically.

• uninitialized memory you can only get from within unsafe code. Yes, you can write memory safety bugs in unsafe code.
• same goes for memory corruption
• use after free is prevented in safe code at compile time
• null pointer de-reference can also only happen in usafe code

Nobody said you cannot program safety bugs in usafe code, I'm sorry.

See above. Nobody claimed that you cannot program unsafe code in unsafe environments. Some pages ago, people said those bugs will happen at the C/interop layer.
Other people think they need unsafe code in their crate to do something fast. But usually this is not required.
There are even tools which list if your dependencies use unsafe code at all.

Again, you can do many things in unsafe code, which will break safety guarantees. In safe code, if you access a vector "out of bounds" your program will panic (at the moment). This is also a way to prevent unsafety - as a last resort. If this is not acceptable, you can use the getters, which check bounds and provide an optional reference.

The bottom line is: when using rust, stick to safe code as much as possible.

Yes I even said myself that many of these are in unsafe code. But that doesn't mean the problems don't exist, that's just hushing up about them. The fact is in Rust you will have these problems too, because as real-life projects have proven repeatedly, unsafe does and must get written a lot. You cannot say "Well, don't write code like that", because that's not realistic and it's not how things work in practice. You're basically arguing "in Rust you can categorically avoid some types of errors by staying clear of specific features". Well guess what, that way you can guarantee memory-safety in C++, C#, and many other languages too. In C++ if you avoid raw pointers and stick to a defined set std:: interfaces you will have no memory-related issues. In C# if you avoid unsafe contexts and mark your code #nullable enable then you'll have no memory issues. And so on. How come you accept the same arguments for Rust but not for other languages? That's a typical tell of an over-hyped crowd.

[oleid]

Yes I even said myself that many of these are in unsafe code. But that doesn't mean the problems don't exist, that's just hushing up about them. The fact is in Rust you will have these problems too, because as real-life projects have proven repeatedly, unsafe does and must get written a lot. You're basically arguing "in Rust you can categorically avoid some types of errors by staying clear of specific features".

I'm arguing: if you want safe code, don't use unsafe. Nothing more, nothing less.

Well guess what, that way you can guarantee memory-safety in C++, C#, and many other languages too. In C++ if you avoid raw pointers and stick to a defined set std:: interfaces you will have no memory-related issues.

And avoid all references. Classic example is: get reference to vector element, push to vector, access reference.