Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • ultimA
    replied
    Originally posted by smitty3268 View Post
    I don't think that's at all what was being said.
    Of course not and I know that too. This was a rhetorical question, meant to point out how wrong their argument is. Because if it was true what they said earlier, this is what it would imply.

    Originally posted by smitty3268 View Post
    The truth of the matter is that rewriting heavily used code almost always introduces new bugs. That's the reason it should only be done for good reasons, and not just on a whim. Old code has generally had lots of users reporting lots of bugs against it, and hopefully had most of those fixed. New code is always going to have some silly mistakes in it, because people aren't perfect. Hopefully moving forward those bug numbers will get even lower, and it will allow for new features/etc. to be added on while not raising the bug numbers too high again.

    If Mozilla really did replace c++ code with a rewritten Rust version and had no change in the # of bugs being found, I'd consider that a massive win. But I'd also say that what's been reported so far on that here isn't nearly specific enough to argue that's what happened one way or another. I think the subject needs way more detailed analysis to take anything away from it one way or another. Just spitballing a couple project-wide stats is pretty useless.
    It seems there is a slight misunderstanding. I didn't say that the bug count for Firefox didn't change after the rewrite. Or anything about whether it changed or in what direction. That is, as you say, hard to tell from such statistics. What I've been pointing out in this thread is that Firefox still has a similar ratio of memory- to non-memory-related CVEs as projects with no Rust at all, even though Firefox has a significant portion of its code written in Rust now. That can only mean one of two things: 1) Either CVE statistics are a bad indicator for the portion of memory-related issues in software, that would mean though the often quoted numbers from similar sources that should prove how bad C++ is are garbage too. 2) Or it could mean Rust is not a magic bullet either when it comes to memory safety. And yes, maybe such issues in Rust all come from unsafe code - I never contradicted that - but if this is the case, I do think this has a lot of implications for Rust codebases, such as the practicality of writing pure-safe code in non-toy projects, or whether Rust's overall security impact is exaggerated in big real-world projects.
    Last edited by ultimA; 13 July 2021, 04:08 AM.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by ultimA View Post
    You are conveniently grabbing onto a single example that happens to not contradict your point.
    You're doing the same thing, though.

    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?
    I don't think that's at all what was being said.

    The truth of the matter is that rewriting heavily used code almost always introduces new bugs. That's the reason it should only be done for good reasons, and not just on a whim. Old code has generally had lots of users reporting lots of bugs against it, and hopefully had most of those fixed. New code is always going to have some silly mistakes in it, because people aren't perfect. Hopefully moving forward those bug numbers will get even lower, and it will allow for new features/etc. to be added on while not raising the bug numbers too high again.

    If Mozilla really did replace c++ code with a rewritten Rust version and had no change in the # of bugs being found, I'd consider that a massive win. But I'd also say that what's been reported so far on that here isn't nearly specific enough to argue that's what happened one way or another. I think the subject needs way more detailed analysis to take anything away from it one way or another. Just spitballing a couple project-wide stats is pretty useless.
    Last edited by smitty3268; 12 July 2021, 09:30 PM.

    Leave a comment:


  • gamerk2
    replied
    Originally posted by oleid View Post
    To sum up my two biggest concerns:

    * C++ won't stop you from reading memory from Thread A while writing from Thread B. rust does, at compile time.
    * C++ won't stop you from using references, which became invalid.
    C++ allows a lot of bad practises; C even more. It's not particularly hard to write bad/unsafe code. The trick is to "not" do that. C/C++ gives the ability to do a LOT of powerful operations at a very high performance level relative to other languages, but those same features are downright dangerous if misused. But that's why C-derived languages have survived so long: despite their MANY pitfalls, it offers the highest level of performance relative to the effort required to code.

    Leave a comment:


  • ultimA
    replied
    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.
    Last edited by ultimA; 08 July 2021, 05:59 AM.

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by silmeth View Post

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

    Leave a comment:


  • silmeth
    replied
    Originally posted by ultimA View Post
    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.

    Leave a comment:


  • ultimA
    replied
    Originally posted by mdedetrich View Post

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

    Originally posted by mdedetrich View Post
    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.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by oleid View Post
    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/

    Leave a comment:


  • ssokolow
    replied
    Originally posted by ultimA View Post
    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.

    Leave a comment:


  • ultimA
    replied
    Originally posted by oleid View Post
    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.


    Originally posted by oleid View Post
    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.
    Last edited by ultimA; 06 July 2021, 05:40 PM.

    Leave a comment:

Working...
X