4 ms·

I love Rust too, but while it likely would have prevented these three bugs, there are many other classes of bugs caused by poorly designed interfaces/abstractio

I love Rust too, but while it likely would have prevented these three bugs, there are many other classes of bugs caused by poorly designed interfaces/abstractions/protocols, misunderstandings, "valid but wrong" logic mistakes, unanticipated interactions, etc. Let's not make magic bullet statements about technology. It's a good way to scare people away...

newsat13 10y ago
> while it likely would have prevented these three bugs Isn't that the point of the parent's comment?
- simion314 10y ago
  I think the point is that Rust fanboy will repeat same thing for years "all security bugs would have been avoided if Rust was used" and when first security issue will be found in Servo or other Rust component(maybe the kernel some Rust devs work on) then Rust reputation will suffer, I see tons of article and blog posts m most of them made to slap the annoyng fanboys that repeated same thing. Btw if they would have used C# then those 3 bugs would not have happen, the thing is that for some work cases you have to do unsafe stuff so C# as Rust has a way to run unsafe code so bug would have happened especially in some low-level code like for a JIT.
  - eridius 10y ago
    OP is correct in saying Rust would have prevented these specific bugs, so I don't understand why you're trying to dismiss them as a "fanboy".
    - simion314 10y ago
      I am 99% sure that OP did not checked the code and made sure that Rust could have been used there without using unsafe, so maybe you could only say "maybe Rust and any other memory safe language would avoid that issue" but since is code related with VMs and JIT you may have use the unsafe things in those languages so maybe it was not avoidable.
      - Ygg2 10y ago
        If the type of bug is use after free, double free, race condition or uninitiated memory - Rust would have dealt with it.
        simion314 10y ago
        And if the code was not part of an unsafe section of Rust code. I have nothing against advocating for your favorite software but if you do it wrong by "omitting" things it will backfire, as a Linux user I seen this thing happen, you get some fanboy convincing people to use Linux, usually Arch because that distro attracts fanboys then the new user finds the ugly parts that were not advertised and runs screaming.
        eridius 10y ago
        This is specious reasoning. You have to go out of your way to write unsafe broken code. The default in Rust is for memory safety. Yes, someone could theoretically be using an unsafe block and raw pointers to manipulate a memory buffer. But they probably aren't, because that's generally pretty stupid unless you're implementing a higher-level wrapper around the buffer, which very few people do because there's generally already a wrapper that does what you want (often provided by the stdlib). And even if you are, the unsafe code is contained in a very small area which makes it much easier to review for safety.
        simion314 10y ago
        I was talking about the low level code like in this case where you interact with the kernel, for calling kernel/OS functions you will have to pass pointers and buffers around,I am not sure if you can wrap the kernel functions without making things slower by adding indirection.
        eridius 10y ago
        For any call that takes a raw pointer and a length, you can create a trivial wrapper that takes a &[u8] or &mut [u8] instead in order to make it safe. And you probably should do that, because you don't want to be sprinkling `unsafe` throughout your entire codebase. If you're really worried about indirection, you can also mark these inline, but they're small enough that the compiler would probably inline them anyway.
  - rapsey 10y ago
    > I think the point is that Rust fanboy will repeat same thing for years "all security bugs would have been avoided if Rust was used" Complete hyperbole. All anyone says is that Rust prevents a class of security issues related to memory access.
problems 10y ago
It likely would prevent the vast majority of bugs that are actively exploited in security breaches. Sure, bad logic bugs happen of course, but more often than not they result in bugs relating only to their own area and often somewhat limited in scope. They're also usually a fairly significant mistake that's often times easier to see - not necessarily all the time, but I'm probably more likely to catch a logic bug in a code review than I am a memory issue beyond a missing free. Memory bugs however are much nastier - even a minor mistake can result in a complete takeover of the system as manipulation of the instruction pointer basically means game over and there are many ways to get that with only a little memory manipulation - blow out the stack until you overwrite the return address, overwrite vtables on the heap, overwrite function pointers, etc. Even a minor off-by-one can result in total exploitation in some scenarios.

newsat13 10y ago

> while it likely would have prevented these three bugs Isn't that the point of the parent's comment?

simion314 10y ago
I think the point is that Rust fanboy will repeat same thing for years "all security bugs would have been avoided if Rust was used" and when first security issue will be found in Servo or other Rust component(maybe the kernel some Rust devs work on) then Rust reputation will suffer, I see tons of article and blog posts m most of them made to slap the annoyng fanboys that repeated same thing. Btw if they would have used C# then those 3 bugs would not have happen, the thing is that for some work cases you have to do unsafe stuff so C# as Rust has a way to run unsafe code so bug would have happened especially in some low-level code like for a JIT.
- eridius 10y ago
  OP is correct in saying Rust would have prevented these specific bugs, so I don't understand why you're trying to dismiss them as a "fanboy".
  - simion314 10y ago
    I am 99% sure that OP did not checked the code and made sure that Rust could have been used there without using unsafe, so maybe you could only say "maybe Rust and any other memory safe language would avoid that issue" but since is code related with VMs and JIT you may have use the unsafe things in those languages so maybe it was not avoidable.
    - Ygg2 10y ago
      If the type of bug is use after free, double free, race condition or uninitiated memory - Rust would have dealt with it.
      - simion314 10y ago
        And if the code was not part of an unsafe section of Rust code. I have nothing against advocating for your favorite software but if you do it wrong by "omitting" things it will backfire, as a Linux user I seen this thing happen, you get some fanboy convincing people to use Linux, usually Arch because that distro attracts fanboys then the new user finds the ugly parts that were not advertised and runs screaming.
        eridius 10y ago
        This is specious reasoning. You have to go out of your way to write unsafe broken code. The default in Rust is for memory safety. Yes, someone could theoretically be using an unsafe block and raw pointers to manipulate a memory buffer. But they probably aren't, because that's generally pretty stupid unless you're implementing a higher-level wrapper around the buffer, which very few people do because there's generally already a wrapper that does what you want (often provided by the stdlib). And even if you are, the unsafe code is contained in a very small area which makes it much easier to review for safety.
        simion314 10y ago
        I was talking about the low level code like in this case where you interact with the kernel, for calling kernel/OS functions you will have to pass pointers and buffers around,I am not sure if you can wrap the kernel functions without making things slower by adding indirection.
        eridius 10y ago
        For any call that takes a raw pointer and a length, you can create a trivial wrapper that takes a &[u8] or &mut [u8] instead in order to make it safe. And you probably should do that, because you don't want to be sprinkling `unsafe` throughout your entire codebase. If you're really worried about indirection, you can also mark these inline, but they're small enough that the compiler would probably inline them anyway.
- rapsey 10y ago
  > I think the point is that Rust fanboy will repeat same thing for years "all security bugs would have been avoided if Rust was used" Complete hyperbole. All anyone says is that Rust prevents a class of security issues related to memory access.

problems 10y ago

It likely would prevent the vast majority of bugs that are actively exploited in security breaches. Sure, bad logic bugs happen of course, but more often than not they result in bugs relating only to their own area and often somewhat limited in scope. They're also usually a fairly significant mistake that's often times easier to see - not necessarily all the time, but I'm probably more likely to catch a logic bug in a code review than I am a memory issue beyond a missing free. Memory bugs however are much nastier - even a minor mistake can result in a complete takeover of the system as manipulation of the instruction pointer basically means game over and there are many ways to get that with only a little memory manipulation - blow out the stack until you overwrite the return address, overwrite vtables on the heap, overwrite function pointers, etc. Even a minor off-by-one can result in total exploitation in some scenarios.