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

[ssokolow]

And none of you has provided an explanation why this shouldn't be the case, only just blank claims that "it isn't and that's it".

How about this:

CVEs don't correlate with the number of bugs present. They correlate with the number of bugs discovered. That means that, if the number of bugs discovered is heavily bottlenecked on the time of skilled bug-finders doing the looking, you may not see a change in the number of CVEs after a partial rewrite, since supply of bugs to be found still greatly outstrips the supply of bug-seekers.

[ultimA]

How about this:

CVEs don't correlate with the number of bugs present. They correlate with the number of bugs discovered. That means that, if the number of bugs discovered is heavily bottlenecked on the time of skilled bug-finders doing the looking, you may not see a change in the number of CVEs after a partial rewrite, since supply of bugs to be found still greatly outstrips the supply of bug-seekers.

If there is a "bottleneck on the time of skilled bug-finders doing the looking", that means less bugs will be found, because basically there is a shortage of human resources. So if less bugs are being found due to a human-resource problem, moreover in a software with less bugs to begin with (because it now has Rust parts), that should result in an even more significant decrease in the number of CVEs, not in the numbers staying constant as you conclude. So I think you have a logic error in your reasoning, and thus this is not the explanation. Unless I misinterpreted something in what you said, in this case please do correct me.

[oleid]

If there is a "bottleneck on the time of skilled bug-finders doing the looking", that means less bugs will be found, because basically there is a shortage of human resources. So if less bugs are being found due to a human-resource problem, moreover in a software with less bugs to begin with (because it now has Rust parts), that should result in an even more significant decrease in the number of CVEs, not in the numbers staying constant as you conclude. So I think you have a logic error in your reasoning, and thus this is not the explanation. Unless I misinterpreted something in what you said, in this case please do correct me.

Na, I don't think it works that way.
Bugs are looked for if there is a bug report. Assuming we have the same amount of bug hunters as before adding rust to firefox (which was the original premise), you argue bugs are harder to find because there are fewer.

One could also argue: bugs are easier findable because it is more obvious where to look for bugs (unsafe blocks, or the C++/rust language interface) or the compiler is more helpful.

But let's face it: anything is possible and somebody should do a research paper about it.

[ultimA]

One could also argue: bugs are easier findable because it is more obvious where to look for bugs (unsafe blocks, or the C++/rust language interface) or the compiler is more helpful.

True, yes, but that would imply the bugs are found in the Rust part. Unsafe blocks, C/Rust interfaces, better compiler diagnostics, are the stuff that come into existence due to the added Rust code. That's exactly the opposite of the assumption that the others were trying to prove (that adding Rust doesn't lead to more bugs found in the new parts). Though I will add here I don't believe a rewrite in Rust will cause more logic bugs to be coded in the new (Rust) code - that was a claim/possibility introduced by another forum member, not me.

But let's face it: anything is possible and somebody should do a research paper about it.

I couldn't agree more. It is really non-obvious why the stats show what they show in either case, irrespective if they tell us anything about Rust's properties or not (ideally, that would be one of the outcomes of the research). I find it sad that some other forum members would rather (wrongly) question basic elementary math or throw about personal insults, instead of simply admitting they don't have a clue either for explaining what they see. They don't question things, just repeat learned mantras.

[ssokolow]

True, yes, but that would imply the bugs are found in the Rust part.

No, it just implies that the presence of Rust makes it easier for bugs to be found. For example, if the use of Rust partitions the C/C++ code in a way which causes less memory corruption to occur before an assert trips, making it easier to locate the cause.

[ssokolow]

Na, I don't think it works that way.
Bugs are looked for if there is a bug report. Assuming we have the same amount of bug hunters as before adding rust to firefox (which was the original premise), you argue bugs are harder to find because there are fewer.

I think this anecdote supports my interpretation (emphasis mine):

Fun fact: while at Mozilla I heard multiple anecdotes of [very intelligent] Firefox developers thinking they had found a bug in Rust's borrow checker because they thought it was impossible for a flagged error to occur. However, after sufficient investigation the result was always (maybe with an exception or two because Mozilla adopted Rust very early) that the Rust compiler was correct and the developer's assertions about how code could behave was incorrect. In these cases, the Rust compiler likely prevented hard-to-debug bugs or even exploitable security vulnerabilities. I remember one developer exclaiming that if the bug had shipped, it would have taken weeks to debug and would likely have gone unfixed for years unless its severity warranted staffing.
-- https://gregoryszorc.com/blog/2021/0...professionals/

[ultimA]

No its not, because its also entirely possible that the code replaced didn't happen to have any bugs because most were ironed out over 10-15 years with plenty of bugs reports/security breaches/CVE's in the past (we are talking about Firefox here). The difference here being that it took Firefox 10-15 years to discover/get rid of said bugs where as a lot of those wouldn't have even compiled in Rust.

You cannot mean this seriously! When I said "come and explain it" I meant provide some plausible explanation, not some random brainfart. You are seriously saying, that after devs at Mozilla invent a new language to get rid of the bugs plaguing their browser, they chose to rewrite exactly that portion of their product which already happens to be free of bugs? Sure, very likely...

Great job demonstrating how both of you guys are more concerned about proving a point rather than being accurate, queue in a golf clap.

Yeah, right back at you. Maybe you should put more effort into thinking and less into personal insults.

[silmeth]

You cannot mean this seriously! When I said "come and explain it" I meant provide some plausible explanation, not some random brainfart. You are seriously saying, that after devs at Mozilla invent a new language to get rid of the bugs plaguing their browser, they chose to rewrite exactly that portion of their product which already happens to be free of bugs? Sure, very likely...

Seems you failed to read the rest of that comment. He was quite clear that they rewrote the part which they couldn’t parallelize using C++ (they tried twice and failed! or at least they claim so here). They managed the first time in Rust.

So yes, they did replace the single-threaded piece of code that was battle-tested and possibly bug-free with new parallelized code in Rust. But it’s not just a simple rewrite, and they tried doing the same in C++ earlier too without success.

[mdedetrich]

Seems you failed to read the rest of that comment. He was quite clear that they rewrote the part which they couldn’t parallelize using C++ (they tried twice and failed! or at least they claim so here). They managed the first time in Rust.

So yes, they did replace the single-threaded piece of code that was battle-tested and possibly bug-free with new parallelized code in Rust. But it’s not just a simple rewrite, and they tried doing the same in C++ earlier too without success.

Exactly, and even claiming it was a "rewrite" is doing it justice., they basically wrote it new completely from scratch (it was actually ported/taken over from Servo).

[ultimA]

You are conveniently grabbing onto a single example that happens to not contradict your point. Even if the motivation of replacing C++ with Rust in Firefox's CSS engine in this specific case was to parallelize it better and not to get rid of bugs, it doesn't change the big picture. The new CSS engine in Rust is only about 85k lines of code according to the same blog post you linked. That is small compared to the whole Rust codebase in Firefox, which is about 2.3M LOC, not counting blank lines and comments (source). The CSS engine is less than only 4% of that! Do you mean in all those 2.3M lines of code, all the original C++ was already free of bugs and it was never Mozilla's intention to solve vulnerabilities, but only better multithreading? You said it yourself too: "... a high chance of introducing security vulnerabilities/bugs which is actually funnily enough the reason why those same Firefox devs came up with Rust".

So your claim still doesn't hold up / add up, and there is no way your claim can explain the discrepancy between the real-world metrics and the theoretically much better memory-safety of Rust.