7 ms·

> I wonder if Firefox will slowly become written in mostly Rust. I doubt that will ever happen. Small parts of Firefox, yes, but the browser is enormous. I thi

> I wonder if Firefox will slowly become written in mostly Rust. I doubt that will ever happen. Small parts of Firefox, yes, but the browser is enormous. I think I once read that even Servo, which is a showcase for Rust, has more C/C++ code in it than Rust code, largely because it uses Firefox's JS engine.

snuxoll 10y ago
SpiderMonkey is probably a long-term target for a Rust replacement or oxidization over time, but considering it is a JIT there's certain classes of issues Rust couldn't help with since native code generation is inherently unsafe.
- Dylan16807 10y ago
  A JIT doesn't have to be any less safe than compiling Rust code.
  - haberman 10y ago
    It seems safe to say that a JIT-trace -> Rust -> machine code compilation pipeline will probably never be fast enough to satisfy the requirements of a high-performance JIT compiler.
    - Dylan16807 10y ago
      Going the long way is just a 'proof of concept' sort of thing. You could design a high-performance JIT around equivalent safety mechanisms, and even prove the tricky parts.
      - haberman 10y ago
        I'll believe it when I see it. :)
      - azakai 10y ago
        In theory, but there isn't even good research on this, AFAIK. Fast JITs for languages like JavaScript require unsafety in the state of the art today.
      - pcwalton 10y ago
        JavaScript's memory model is incompatible with that of Rust anyhow. You would want something like typed assembly language (Google this--it's a fertile research area). Very researchy though, with uncertain payoff. But note that a lot of security problems are not in the jitcode but rather in C++ implementations of JS objects and in the compiler itself.
        nickpsecurity 10y ago
        BOOM! Typed, assembly language is exactly what I was going to recommend! TALC assembly, Chlipala's Bedrock, and Microsoft's CoqASM are Google keywords to use for anyone following along. CakeML or Verisoft's C0 could be useful for assembly generation but not as sure there. Tough constraints in JIT. Edited to add Myreen's JIT that I just remembered. http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=F58CA1EA4E767AE101854A3B87BD0739?doi=10.1.1.154.6457&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=F58...
        dman 10y ago
        CoqASM looks interesting! Is it publicly available anywhere?
        nickpsecurity 10y ago
        Not that Im aware of. They might privately license it if asked. I mainly bring it up as something worth cloning by FOSS team given there's plenty details in paper. Meanwhile, look up Magnus Myreen's publications and software as they're on a row with verified everything.
        moosingin3space 10y ago
        Typed assembly language would be an excellent addition to the Rust ecosystem -- there are still segments of software which should (or must) be implemented in assembly, so anything that can help make assembly easier to verify would be helpful to the ecosystem.
  - comex 10y ago
    No, but to be safe enough it has to be more safe than the Rust compiler, because the latter doesn't get run on untrusted code (with the result automatically executed)[1]. If bounds checks exist in the compiler IR, they're subject to optimization, which is very helpful for performance but also risky, as incorrect optimizations can easily cause memory unsafety. Optimizer bugs in modern backends are rarely encountered in practice, but from a security perspective, that's like saying your C++ program never crashes in practice: it helps, but it doesn't prove the absence of bugs that can only be triggered by pathological inputs; such bugs in fact tend to be quite common. I've never tried to find an optimizer bug in LLVM, but I have found more than one in V8, so I have some idea what I'm talking about. [1] More specifically, this doesn't happen in situations where correctness of the generated code is relied on to provide safety guarantees. There are several websites that will compile and run Rust code for you, but none of them try to ban unsafe code, or filesystem/syscall access for that matter, at the language level; rather, their security model relies entirely on the OS sandbox the process runs in. Google's PNaCl uses (or used to use?) LLVM on untrusted code, but AFAIK the output of LLVM, the machine instructions, are still run through the NaCl validator, so getting LLVM to miscompile something wouldn't accomplish much. (NaCl also runs both LLVM itself and the untrusted code in an OS sandbox.)
- bluejekyll 10y ago
  How about starting with WebAssembly... should have less scope.
  - steveklabnik 10y ago
    The people who would work on these two things are pretty disjoint, or at least, I'm not aware of any SpiderMonkey people working on our wasm support. So it's not really an either-or kind of proposition.
    - infogulch 10y ago
      I wonder if you could ship a fully featured javascript engine written in WebAssembly. Then servo could just include that and it would interpret/JIT the rest of the JS.
bluejekyll 10y ago
> I think I once read that even Servo, which is a showcase for Rust, has more C/C++ code in it than Rust code Not in the core project: https://github.com/servo/servo https://github.com/servo/servo
- lovelettr 10y ago
  Where is the feature in GitHub that would show the languages used in a repository? That would be useful here regarding this comment. (Note I have no doubt you are right. It would just be a useful metric.)
  - dvlsg 10y ago
    Do they still have the colored lines towards the top? I think you have to click on it to see the language percentage breakdown.
  - whateveracct 10y ago
    Did they just..get rid of it? I can't find it either.
    - szatkus 10y ago
      No, it works for other repostiories. Probably Github uses cloc. I downloaded the code (over 500MB, insane!) and cloc throws an error.
      - steveklabnik 10y ago
        > and cloc throws an error tokei is a similar program that's parallel, and written in Rust. It takes 11 seconds to run on my machine, and shows https://gist.github.com/steveklabnik/b4ede6f13c9d609edc61d7421e0af1b1 https://gist.github.com/steveklabnik/b4ede6f13c9d609edc61d74... (using a gist since the output is huge, and see Manish's comment as well)
        Manishearth 10y ago

snuxoll 10y ago

SpiderMonkey is probably a long-term target for a Rust replacement or oxidization over time, but considering it is a JIT there's certain classes of issues Rust couldn't help with since native code generation is inherently unsafe.

Dylan16807 10y ago
A JIT doesn't have to be any less safe than compiling Rust code.
- haberman 10y ago
  It seems safe to say that a JIT-trace -> Rust -> machine code compilation pipeline will probably never be fast enough to satisfy the requirements of a high-performance JIT compiler.
  - Dylan16807 10y ago
    Going the long way is just a 'proof of concept' sort of thing. You could design a high-performance JIT around equivalent safety mechanisms, and even prove the tricky parts.
    - haberman 10y ago
      I'll believe it when I see it. :)
    - azakai 10y ago
      In theory, but there isn't even good research on this, AFAIK. Fast JITs for languages like JavaScript require unsafety in the state of the art today.
    - pcwalton 10y ago
      JavaScript's memory model is incompatible with that of Rust anyhow. You would want something like typed assembly language (Google this--it's a fertile research area). Very researchy though, with uncertain payoff. But note that a lot of security problems are not in the jitcode but rather in C++ implementations of JS objects and in the compiler itself.
      - nickpsecurity 10y ago
        BOOM! Typed, assembly language is exactly what I was going to recommend! TALC assembly, Chlipala's Bedrock, and Microsoft's CoqASM are Google keywords to use for anyone following along. CakeML or Verisoft's C0 could be useful for assembly generation but not as sure there. Tough constraints in JIT. Edited to add Myreen's JIT that I just remembered. http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=F58CA1EA4E767AE101854A3B87BD0739?doi=10.1.1.154.6457&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=F58...
        dman 10y ago
        CoqASM looks interesting! Is it publicly available anywhere?
        nickpsecurity 10y ago
        Not that Im aware of. They might privately license it if asked. I mainly bring it up as something worth cloning by FOSS team given there's plenty details in paper. Meanwhile, look up Magnus Myreen's publications and software as they're on a row with verified everything.
      - moosingin3space 10y ago
        Typed assembly language would be an excellent addition to the Rust ecosystem -- there are still segments of software which should (or must) be implemented in assembly, so anything that can help make assembly easier to verify would be helpful to the ecosystem.
- comex 10y ago
  No, but to be safe enough it has to be more safe than the Rust compiler, because the latter doesn't get run on untrusted code (with the result automatically executed)[1]. If bounds checks exist in the compiler IR, they're subject to optimization, which is very helpful for performance but also risky, as incorrect optimizations can easily cause memory unsafety. Optimizer bugs in modern backends are rarely encountered in practice, but from a security perspective, that's like saying your C++ program never crashes in practice: it helps, but it doesn't prove the absence of bugs that can only be triggered by pathological inputs; such bugs in fact tend to be quite common. I've never tried to find an optimizer bug in LLVM, but I have found more than one in V8, so I have some idea what I'm talking about. [1] More specifically, this doesn't happen in situations where correctness of the generated code is relied on to provide safety guarantees. There are several websites that will compile and run Rust code for you, but none of them try to ban unsafe code, or filesystem/syscall access for that matter, at the language level; rather, their security model relies entirely on the OS sandbox the process runs in. Google's PNaCl uses (or used to use?) LLVM on untrusted code, but AFAIK the output of LLVM, the machine instructions, are still run through the NaCl validator, so getting LLVM to miscompile something wouldn't accomplish much. (NaCl also runs both LLVM itself and the untrusted code in an OS sandbox.)
bluejekyll 10y ago
How about starting with WebAssembly... should have less scope.
- steveklabnik 10y ago
  The people who would work on these two things are pretty disjoint, or at least, I'm not aware of any SpiderMonkey people working on our wasm support. So it's not really an either-or kind of proposition.
  - infogulch 10y ago
    I wonder if you could ship a fully featured javascript engine written in WebAssembly. Then servo could just include that and it would interpret/JIT the rest of the JS.

bluejekyll 10y ago

> I think I once read that even Servo, which is a showcase for Rust, has more C/C++ code in it than Rust code Not in the core project: https://github.com/servo/servo https://github.com/servo/servo

lovelettr 10y ago
Where is the feature in GitHub that would show the languages used in a repository? That would be useful here regarding this comment. (Note I have no doubt you are right. It would just be a useful metric.)
- dvlsg 10y ago
  Do they still have the colored lines towards the top? I think you have to click on it to see the language percentage breakdown.
- whateveracct 10y ago
  Did they just..get rid of it? I can't find it either.
  - szatkus 10y ago
    No, it works for other repostiories. Probably Github uses cloc. I downloaded the code (over 500MB, insane!) and cloc throws an error.
    - steveklabnik 10y ago
      > and cloc throws an error tokei is a similar program that's parallel, and written in Rust. It takes 11 seconds to run on my machine, and shows https://gist.github.com/steveklabnik/b4ede6f13c9d609edc61d7421e0af1b1 https://gist.github.com/steveklabnik/b4ede6f13c9d609edc61d74... (using a gist since the output is huge, and see Manish's comment as well)
      - Manishearth 10y ago