5 ms·

Great. I think this is the kind of booster Rust sorely needed.

by geodel 7y ago

ncmncm 7y ago
When security holes in Libra implementations surface, that will reflect badly on Rust. There will of course be explanations why the holes are really not Rust's fault, and that bugs and security failings are possible in any language, but it will force a more realistic assessment of Rust's strengths.
- geodel 7y ago
  Right. And I think it is reasonable thing to happen. Languages can't mature without big public successes and failures.
- JoshTriplett 7y ago
  There have already been such assessments. For instance, in https://hacks.mozilla.org/2019/02/rewriting-a-browser-component-in-rust/ https://hacks.mozilla.org/2019/02/rewriting-a-browser-compon... , Mozilla estimated that writing a given browser component (specifically the CSS engine) in Rust, 51 of its 69 security bugs (73.9%) wouldn't have happened. The other 18 weren't things that the implementation language doesn't inherently help with.
  - blub 7y ago
    The problem with Mozilla's C++ code is that it was developed in a time where memory-safety was an afterthought and they're still paying for that. Rewriting it in anything will offer a great opportunity of improving it. For example, the real fix for their vulnerable code example is using automatic bounds checking, just as Rust does. Replacing [] with at, eliminates the vulnerability. Most C++ programmers are allergic to at, so Mozilla could have created some container wrappers that do this by default. GCC and I think also clang have a macro which adds automatic bounds-checking to the STL containers.
    - JoshTriplett 7y ago
      > Replacing [] with at, eliminates the vulnerability. And for decades of C and C++ programmers, [] is still the most obvious way to index an array. And the most obvious way creates potential security vulnerabilities. See Rusty Russell's classic "easy to use versus hard to misuse" posts: http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html and https://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html https://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html .
      - blub 7y ago
        Historically, C and C++ programmers didn't care much about safety, especially if they had to give up performance to reach it. This is changing in the newest C++ standards and tooling (e.g. clang's -Wlifetimes). Bounds checking is slower, so that's the main reason why it's shunned. Rust made it mandatory, but from what I've seen there are people disabling that to squeeze some drops of performance nevertheless. Luckily, I think Rust also has an option of replacing indexing with iteration, thereby avoiding the performance hit. I think it currently does this a bit better than C++, but I might be wrong. Anyway, my critique still stands, that blog post is really low effort and doesn't prove much. I've looked at some of the fixes for Firefox security bugs and the code reminds one of the typical older C++ projects with raw pointers everywhere. Perhaps implementing a browser requires all sorts of unsafe access patterns.
        JoshTriplett 7y ago
        The Rust compiler can eliminate bounds checking anywhere it can prove that it doesn't need it. And beyond that, you always have the option of writing an unsafe block, and people sometimes do in carefully selected cases driven by profiling. (That also encourages keeping such code carefully contained and well-scrutinized.) I'm not arguing that bounds-checking should be mandatory. I'm arguing that bounds-checking should be the default, and you should have to knowingly bypass it, rather than the other way around.
    - staticassertion 7y ago
  - ncmncm 7y ago
    I wrote "more realistic" deliberately. C++ is coded quite differently today than when Gecko was written -- at least, in places where the official Coding Standard does not forbid it. Mozilla and Google's do. After the more-realistic assessment, claims about Rust's inherent safety will need to be walked back some. It will still be an enormous improvement on C.

Great. I think this is the kind of booster Rust sorely needed.

by geodel 7y ago

Great. I think this is the kind of booster Rust sorely needed.

When security holes in Libra implementations surface, that will reflect badly on Rust. There will of course be explanations why the holes are really not Rust's fault, and that bugs and security failings are possible in any language, but it will force a more realistic assessment of Rust's strengths.

geodel 7y ago
Right. And I think it is reasonable thing to happen. Languages can't mature without big public successes and failures.
JoshTriplett 7y ago
There have already been such assessments. For instance, in https://hacks.mozilla.org/2019/02/rewriting-a-browser-component-in-rust/ https://hacks.mozilla.org/2019/02/rewriting-a-browser-compon... , Mozilla estimated that writing a given browser component (specifically the CSS engine) in Rust, 51 of its 69 security bugs (73.9%) wouldn't have happened. The other 18 weren't things that the implementation language doesn't inherently help with.
- blub 7y ago
  The problem with Mozilla's C++ code is that it was developed in a time where memory-safety was an afterthought and they're still paying for that. Rewriting it in anything will offer a great opportunity of improving it. For example, the real fix for their vulnerable code example is using automatic bounds checking, just as Rust does. Replacing [] with at, eliminates the vulnerability. Most C++ programmers are allergic to at, so Mozilla could have created some container wrappers that do this by default. GCC and I think also clang have a macro which adds automatic bounds-checking to the STL containers.
  - JoshTriplett 7y ago
    > Replacing [] with at, eliminates the vulnerability. And for decades of C and C++ programmers, [] is still the most obvious way to index an array. And the most obvious way creates potential security vulnerabilities. See Rusty Russell's classic "easy to use versus hard to misuse" posts: http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html and https://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html https://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html .
    - blub 7y ago
      Historically, C and C++ programmers didn't care much about safety, especially if they had to give up performance to reach it. This is changing in the newest C++ standards and tooling (e.g. clang's -Wlifetimes). Bounds checking is slower, so that's the main reason why it's shunned. Rust made it mandatory, but from what I've seen there are people disabling that to squeeze some drops of performance nevertheless. Luckily, I think Rust also has an option of replacing indexing with iteration, thereby avoiding the performance hit. I think it currently does this a bit better than C++, but I might be wrong. Anyway, my critique still stands, that blog post is really low effort and doesn't prove much. I've looked at some of the fixes for Firefox security bugs and the code reminds one of the typical older C++ projects with raw pointers everywhere. Perhaps implementing a browser requires all sorts of unsafe access patterns.
      - JoshTriplett 7y ago
        The Rust compiler can eliminate bounds checking anywhere it can prove that it doesn't need it. And beyond that, you always have the option of writing an unsafe block, and people sometimes do in carefully selected cases driven by profiling. (That also encourages keeping such code carefully contained and well-scrutinized.) I'm not arguing that bounds-checking should be mandatory. I'm arguing that bounds-checking should be the default, and you should have to knowingly bypass it, rather than the other way around.
  - staticassertion 7y ago
- ncmncm 7y ago
  I wrote "more realistic" deliberately. C++ is coded quite differently today than when Gecko was written -- at least, in places where the official Coding Standard does not forbid it. Mozilla and Google's do. After the more-realistic assessment, claims about Rust's inherent safety will need to be walked back some. It will still be an enormous improvement on C.