Results of the Google Native Client security contest
googlecode.blogspot.com
googlecode.blogspot.com
Modeling/Simulation/etc. certainly benefits from running on the metal. But, with the exception of SETI@Home, etc., nobody runs untrusted simulation code. Games are the obvious target. A webby sort of Photoshop might also benefit. What else?
Am I wrong to think it obvious that Google's goal is to do away with the last major reason(s) to run Windows? Is there any other benefit to being so close to the metal when we have nice, sandboxed VMs that JIT compile quite efficient code?
My arguments for NaCl:
1. Rewriting C code in Java is expensive.
2. JITs do a poor job on SIMD code that is used in multimedia.
Other cool uses, would be basically turning user's computers into grid computing nodes.
Oh, and of course now being to have any language run in the browser as long as you can get it's code ported to work on their modified compiler.
No, just many flaws in the implementation that allowed unverified code to be run and make sys calls.
Seems like quite a disingenuous statement.
> In the contest build, there were instruction sequences found that could jailbreak you from the sandbox.
From this link, which is fascinating & thoughtful on the topic:
http://www.matasano.com/log/1674/the-security-implications-o...
The vulnerability you're talking about is a straightforward implementation flaw. Admittedly, it's a flaw NaCL's design begs you to make: forgetting about an aspect of x86 encoding is a problem you only have if you're going to let raw x86 instructions hit the processor. But the fix for it is no harder than the fix for, say, an implementation fault in the ELF loader code.
But I'm inclined to say that "they're at greater risk of implementation flaws because of their design" -- and unlike you, for me I believe that itself does actually count as a design flaw.
(And on a side topic/rant since you mention the ELF loader: were I to have Google's resources, I would be far more paranoid than they about this whole thing. e.g.: the ELF loader doesn't need to be fantastically speedy; why not write it using tools/languages with stronger guarantees of memory safety? (That would hold for anything that wasn't inner-loop stuff, as well.)
Another example: The verifier & safety of the allowed instructions are the crown jewels; why not hire the pointy-headed folks who do formal verification for some stronger assurances that the allowed instructions really are safe and that the verifier is complete?)
Edit to add: And if changing the language & tooling isn't feasible, they could have at least pulled a neat trick and run the ELF loader (and similarly exposed code) within their own sandbox, rather than outside of it.