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

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

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

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

[oleid]

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)

From what I've heard about the discussion in systemd on adding rust, it is hard to find C maintainers. Probably harder for the 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,

It is a long time before this is going to be used. By then, dust has settled.

[oleid]

I didn't but no need. The point is if we assume that the part of C++ code that was rewritten in Rust had percentage-wise as many memory-issues before the rewrite as the non-rewritten parts (and this is a sound assumption because the main motivation for the rewrite is to get rid of such bugs), and the rewrite in Rust eliminated most if not all memory issues, then after

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

the rewrite we should see that much less memory-issues as the percentage of code that was rewritten. And this is not what we see. In fact, we see no change at all. Or do you mean to imply that rewriting 20% of code in Rust automatically introduces 20% more safety-issues in other parts of the code? Surely not.

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

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

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

[ShFil]

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,

[oleid]

The list was created by simply searching for Rust, so there is a small number of false positives there which aren't Rust. But if you take a look at that list under the original link (and you took), then you see it is overwhelmingly and mostly Rust code. So by quoting one item of the 5% on that list which is not Rust, you are distracting from the facts by making the list look invalid when it is not.

The first was not rust. The 2nd was already in rust code. But if you read what I wrote carefully, I'm not distracting from anything. I explicitly wrote:

So no, rust doesn't make your programs magically bug-free. But it usually eliminates one source of bugs.

[ultimA]

Furthermore, how did you find out which of those firefox-CVEs are in rust code? Last time I checked I did it manually for a few bugs, which is a lot of work.

I didn't but no need. The point is if we assume that the part of C++ code that was rewritten in Rust had percentage-wise as many memory-issues before the rewrite as the non-rewritten parts (and this is a sound assumption because the main motivation for the rewrite is to get rid of such bugs), and the rewrite in Rust eliminated most if not all memory issues, then after the rewrite we should see that much less memory-issues as the percentage of code that was rewritten. And this is not what we see. In fact, we see no change at all. Or do you mean to imply that rewriting 20% of code in Rust automatically introduces 20% more safety-issues in other parts of the code? Surely not.

[ultimA]

• A flaw was discovered in GNU libiberty within demangle_path() in rust-demangle.c [...]
  This is actually C code
• Deno is a runtime for JavaScript and TypeScript that uses V8 and is built in Rust [...]
  That's a logic bug in JavaScript import
• An issue was discovered in the algorithmica crate [...]
  That's a logic error resulting in double-free
• An issue was discovered in the rkyv crate [...]
  That's a logic error resulting in broken serialization
• In the standard library in Rust before 1.52.0, a double free can occur in the Vec::from_iter function if freeing the element panics. [...]
  Double free if freeing panics
• [the next 11 or something entries]
  Again double free if freeing panics
• In the standard library in Rust before 1.52.0, the Zip implementation can report an incorrect size due to an integer overflow
  Not nice...

The list was created by simply searching for Rust, so there is a small number of false positives there which aren't Rust. But if you take a look at that list under the original link (and you took), then you see it is overwhelmingly and mostly Rust code. So by selectively quoting one or two item of the 5% on that list which is not Rust, you are distracting from the facts by making the list look invalid when it is not.

[ultimA]

Sorry, double-post.