Even if Servo doesn't pan out as anything more than an experiment (though I'm optimistic that it will), I think Rust will bring real benefits to Firefox by enhancing security of isolated components like this mp4 parser.
> 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.
"core project" is a nebulous term. Stuff is in that repo when it doesn't make sense to break it off as a crate; and a lot of our code is broken off as a crate. But yes, the servo team rarely hacks directly on the C++ components. (we hack very often on Rust out of tree things though)
The C++ code is in servo/mozjs and servo/skia (though that dependency doesn't get used on a default run now IIRC), as well as some other scattered deps and native linkages (fontconfig, harfbuzz, openssl, etc)
We've split the code up in crates so servo/servo is only a fraction of the story. Things in servo/servo are usually components which don't make much sense as something you'd independently use, and are very servo-specific and/or tightly coupled. But a lot of our Rust code is outside the tree, and any C++ modules we use are too.
Also, he vast majority of code in servo/servo is actually HTML/JS test code, vendored in tree from w3c/web-platform-tests.
I built Servo last week, I ran "git fetch upstream && git reset --hard upstream/master && git submodule update" and then "tokei .". So, unless Servo puts its cache in the dir, I would guess not, no.
I think by default servo does put the cache in the dir. So yeah, this would be an accurate estimate.
Though not all that rust code is written specifically for servo, and a lot of that C/++ code is winapi and skia. winapi is autogenerated, and skia isn't used by default anymore iirc.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
> real benefits to Firefox by enhancing security of isolated components like this mp4 parser
Now if only there was a way to isolate stuff at runtime (i.e. a sandbox) to better take advantage of operating system mitigations. I hope that with e10s now (almost) shipping we will start to see some progress towards this. IIRC Mozilla has said they would start to roll out security features (related to e10s) in stages. I'll believe it when I see it but it's nice to finally see this from Firefox since it's been far too long without a defense in depth approach to security from them.
Tried rust on my old c2d, feels like alpha level. I thought they'd be closer to a "wow" effect from parallel tree rendering but not in my 4 minutes test. Crashes and memory exhaustion.
Still wishes a safe parallel renderer to emerge so good luck to the team.
