4 ms·

Not bad but a little bit of a publicity stunt. A major source of vulnerabilities is (still) the Javascript engine and that's (still) written in C++. Even wors

Not bad but a little bit of a publicity stunt. A major source of vulnerabilities is (still) the Javascript engine and that's (still) written in C++. Even worse, as far as I know, Mozilla has no plans to rewrite even parts of Spidermonkey in Rust. For some recent examples: https://usn.ubuntu.com/3688-1/ https://usn.ubuntu.com/3688-1/ https://usn.ubuntu.com/3749-1/ https://usn.ubuntu.com/3749-1/

gpm 8y ago
> Mozilla has no plans to rewrite even parts of Spidermonkey in Rust. Here's a substantial part being rewritten in rust by Mozilla: https://github.com/CraneStation/cranelift/blob/master/spidermonkey.md#phase-2-ionmonkey https://github.com/CraneStation/cranelift/blob/master/spider...
- insertcredit 8y ago
  I am not sure I would call cranelift "substantial" in terms of exposure/usage. From what I gather, it's not used at all for normal, everyday Javascript. I stand corrected though, every little bit helps. Here's hope they'll start using Rust in more places where it counts.
  - gpm 8y ago
    I suppose "substantial" is subjective, but I really do thing it counts. Certainly their are unfortunately frequent vulnerabilities in the code it intends to replace. For example: https://bugzilla.mozilla.org/show_bug.cgi?id=1493900 https://bugzilla.mozilla.org/show_bug.cgi?id=1493900 https://bugzilla.mozilla.org/show_bug.cgi?id=1493903 https://bugzilla.mozilla.org/show_bug.cgi?id=1493903 To be fair I'm not actually sure rust would fix either of the CVEs I linked. Both being about problems in the generated code (as I understand them from a glance), which is something inherently unsafe to do. Edit: I realized you might be picking out the word "ARM" on that page. I know Crainlift also works on x86, and I assume it's intended to replace IonMonkey everywhere, not just on ARM chips.
devwastaken 8y ago
Rust isn't just for Firefox. I'm unsure if Safe Rust works with JIT compilation. Unless some new method comes around jit is King when it comes to JavaScript.
- gpm 8y ago
  > I'm unsure if Safe Rust works with JIT compilation. I mean, if you just want to compile the code, sure. Executing arbitrary machine code not generated by the rust compiler (i.e. by the JIT compiler you wrote in rust) is basically the definition of unsafe though...
ridiculous_fish 8y ago
A JS engine is a high-risk, high-reward problem for Rust. High-reward because JS engines are, to your point, a major source of vulnerabilities; high-risk because JS-engine theory is rather outside of Rust's wheelhouse. One class of vulnerabilities in JS engines is use-after-move. A raw pointer is extracted, an allocating function is called (triggering a GC), then the raw pointer is used, pointing into nowhere. It's awkward to express in Rust that a function may modify state inaccessible from its parameters. A second class of vulnerabilities is type-confusion. A value is resolved to (a pointer to) some concrete type, but some later code mutates the value. Now the concrete type is wrong. Again this possibility is awkward to express in Rust. The problem is complicated by the NaN-boxing and JIT aspects of JS engines, which interfere with Rust's tree-ownership dreams. People smarter and way better at Rust than myself are working on it; I'm excited by the prospect of novel solutions that can defeat entire classes of problems.
- johncolanduoni 8y ago
  I'm curious what proportion of vulnerabilities in JS engines are due to mis-generated JIT code vs direct errors in their compiled code. Rust allows you to express some nice properties not always directly related to memory safety (e.g. checked consumption, convenient and safe ADTs), but unless there is a novel application of these facilities to the structure of a JIT engine it won't help a ton with the former kind of vulnerabilities. I'm excited to see a practical programming language that implements full dependent typing; languages like Idris are actually really good at dealing with precisely the kinds of situations you mention.
  - ridiculous_fish 8y ago
    JS engines have many parts implemented natively, which may be called from JS, and in turn call back into JS. An example is CVE-2015-6764: this grabs an array length, which quickly becomes stale, because accessing one of the array's elements invokes a custom toJSON which in turn modifies the array's length. This feels like a hopeless problem; can any of Rust's powers be brought to bear here? Could Idris?
jandem 8y ago
SpiderMonkey dev here. As others have mentioned, Cranelift is one component that's being written in Rust. Eventually we want to use Cranelift as compiler backend not just for WebAssembly but also for JS. After that it might be feasible to port more of the JS JIT to Rust. It might also make sense to use Rust for the parser or regular expression engine, who knows. There will probably always be C++ code in Gecko, but I firmly believe that writing more components in Rust instead of C++ will (in general) improve security and developer productivity. It still amazes me that we're actually shipping a browser with a CSS engine (and soon graphics engine!) written in Rust. Even more amazing is that these components are mostly shared with an entirely different browser engine.

gpm 8y ago

> Mozilla has no plans to rewrite even parts of Spidermonkey in Rust. Here's a substantial part being rewritten in rust by Mozilla: https://github.com/CraneStation/cranelift/blob/master/spidermonkey.md#phase-2-ionmonkey https://github.com/CraneStation/cranelift/blob/master/spider...

insertcredit 8y ago
I am not sure I would call cranelift "substantial" in terms of exposure/usage. From what I gather, it's not used at all for normal, everyday Javascript. I stand corrected though, every little bit helps. Here's hope they'll start using Rust in more places where it counts.
- gpm 8y ago
  I suppose "substantial" is subjective, but I really do thing it counts. Certainly their are unfortunately frequent vulnerabilities in the code it intends to replace. For example: https://bugzilla.mozilla.org/show_bug.cgi?id=1493900 https://bugzilla.mozilla.org/show_bug.cgi?id=1493900 https://bugzilla.mozilla.org/show_bug.cgi?id=1493903 https://bugzilla.mozilla.org/show_bug.cgi?id=1493903 To be fair I'm not actually sure rust would fix either of the CVEs I linked. Both being about problems in the generated code (as I understand them from a glance), which is something inherently unsafe to do. Edit: I realized you might be picking out the word "ARM" on that page. I know Crainlift also works on x86, and I assume it's intended to replace IonMonkey everywhere, not just on ARM chips.

devwastaken 8y ago

Rust isn't just for Firefox. I'm unsure if Safe Rust works with JIT compilation. Unless some new method comes around jit is King when it comes to JavaScript.

gpm 8y ago
> I'm unsure if Safe Rust works with JIT compilation. I mean, if you just want to compile the code, sure. Executing arbitrary machine code not generated by the rust compiler (i.e. by the JIT compiler you wrote in rust) is basically the definition of unsafe though...

ridiculous_fish 8y ago

A JS engine is a high-risk, high-reward problem for Rust. High-reward because JS engines are, to your point, a major source of vulnerabilities; high-risk because JS-engine theory is rather outside of Rust's wheelhouse. One class of vulnerabilities in JS engines is use-after-move. A raw pointer is extracted, an allocating function is called (triggering a GC), then the raw pointer is used, pointing into nowhere. It's awkward to express in Rust that a function may modify state inaccessible from its parameters. A second class of vulnerabilities is type-confusion. A value is resolved to (a pointer to) some concrete type, but some later code mutates the value. Now the concrete type is wrong. Again this possibility is awkward to express in Rust. The problem is complicated by the NaN-boxing and JIT aspects of JS engines, which interfere with Rust's tree-ownership dreams. People smarter and way better at Rust than myself are working on it; I'm excited by the prospect of novel solutions that can defeat entire classes of problems.

johncolanduoni 8y ago
I'm curious what proportion of vulnerabilities in JS engines are due to mis-generated JIT code vs direct errors in their compiled code. Rust allows you to express some nice properties not always directly related to memory safety (e.g. checked consumption, convenient and safe ADTs), but unless there is a novel application of these facilities to the structure of a JIT engine it won't help a ton with the former kind of vulnerabilities. I'm excited to see a practical programming language that implements full dependent typing; languages like Idris are actually really good at dealing with precisely the kinds of situations you mention.
- ridiculous_fish 8y ago
  JS engines have many parts implemented natively, which may be called from JS, and in turn call back into JS. An example is CVE-2015-6764: this grabs an array length, which quickly becomes stale, because accessing one of the array's elements invokes a custom toJSON which in turn modifies the array's length. This feels like a hopeless problem; can any of Rust's powers be brought to bear here? Could Idris?

jandem 8y ago

SpiderMonkey dev here. As others have mentioned, Cranelift is one component that's being written in Rust. Eventually we want to use Cranelift as compiler backend not just for WebAssembly but also for JS. After that it might be feasible to port more of the JS JIT to Rust. It might also make sense to use Rust for the parser or regular expression engine, who knows. There will probably always be C++ code in Gecko, but I firmly believe that writing more components in Rust instead of C++ will (in general) improve security and developer productivity. It still amazes me that we're actually shipping a browser with a CSS engine (and soon graphics engine!) written in Rust. Even more amazing is that these components are mostly shared with an entirely different browser engine.