Hacker News Reader

Comment by andrewchambers | Hacker News Reader

Unfortunately I think the increased complexity in javascript engines is also a security risk.

Fuzzing and other techniques may be able to cause all sorts of crashes and memory corruptions in the jit compilers code or in the generated code. This issue may have just been amplified by the extra complexity in the massive amount of LLVM C++ code added.

This is less of an issue for llvm when used as a static compiler, but as a jit on untrusted code, I don't know.

Time will tell, but I wonder if Rusts memory safety will make it a better candidate for implementing advanced JIT engines that process untrusted code than C++ like in LLVM.

View on HN

Surely complexity always creates risk. The question is whether the tradeoff is acceptable.

Everyone is optimizing the hell out of their Javascript engines right now -- the question is whether some jit that's cobbled together independently of any other codebase is going to be intrinsically superior to a compiler that's being used for lots of other things (obviously there are arguments in both directions, right?). Is it better to simultaneously support Javascript via V8 (which has tiered optimizations of its own), Dart both via compilation to Javascript and its own independently optimized runtime, and NaCl? Is it better to have Javascript and asm.js?

Your trusty Apple II will be immune to modern malware thanks to the simplicity of not being able to connect to the internet, run 32-bit software, or have more than 48kB of memory. Of course the Apple II did have at least one virus.

A JIT is inherently unsafe, since you're creating (nearly) arbitrary code, so, IMO, the largest benefit Rust can give to a JIT is possibly making it easier to write correct code, since memory safety of the code generator is somewhat orthogonal to memory safety of the generated code.

(NB. it isn't necessarily the case that Rust makes writing correct code easier, but features like ADTs and pattern matching seem like they would be useful for such things.)

I was partially referring to LLVM segfaulting sometimes on bad input, but its correct to say even without segfaults in the compiler itself, just generating incorrect code via any other bug could cause the same issues.

LLVM is interesting in that it's far less mature as a JIT than as a static compiler. I think using llvm as a browser JIT specifically may raise the bar for how the LLVM people need to consider security in the code.

Though that being said, compilers are already some of our most critical and trusted code.

> Fuzzing and other techniques may be able to cause all sorts of crashes and memory corruptions in the jit compilers code or in the generated code. This issue may have just been amplified by the extra complexity in the massive amount of LLVM C++ code added.

But to be consistent with the web's development, such risks should not be considered in advance (this would spoil the fun, after all!), but bolted on in vendor specific ways as an afterthought (so that the vendors can be continued to be ridiculed for their incompetency, which makes "full-stack-engineers" feel warm and fuzzy).

This is why some browsers don't trust any code running in the webpage and sandbox everything in it

And Apple is forcing all other browsers to use its JS engine on iOS - so when Safara/its JS engine falls, they all fall.

Half untrue -- Apple allows you to use third-party JS engines on iOS. I've seen SpiderMonkey and Jurrasic (C#) used on iOS.

What they don't allow third parties to do is JIT compile. The "execute writeable pages" entitlement is only allowed to Safari and in iOS 8 WKWebViews.

So your bigger point stands -- third party browsers all need to use a single JS implementation if they want to have the speed of a JIT.

I think I prefer a single trusted implementation by Apple to N implementations by whoever wants to give it a shot.

With that logic applied to Windows, V8 would never have seen the light of day.

But that misses the other side of the argument, a fix for them is a fix for everyone and improvements to core are free improvements for everyone.

By that logic we should all be happy that Flash isn't a spec implemented in 4 different browsers, but rather on monolithic monster from one company, in all of them.

Which also emphasizes the point that Apple wouldn't ship this sort of code on iOS if it wasn't properly secured.

Reply on news.ycombinator.com