Apple, which has started distributing LLVM bitcode, will be able to apply it on all the new apps in the App Store transparently.
Google will be able to do likewise for NaCL apps.
Google will be able to do likewise for NaCL apps.
All 5 of them?
No they won't, because NaCl is native x86. Unless you mean PNaCl, which is a different technology with much less adoption than NaCl.
So technically bother, then? NaCL programs are just as susceptible to buffer-overflow as conventional programs, its just they are better sandboxed. Exploit mitigation is a belt-and-braces thing, and I can't see why Google wouldn't be enabling this pass right now as we speak.
You have something compiled in NaCL like the Flash plugin and it can control the camera and stuff and you are hoping that an attacker can't feed it some malformed JPEG or something that makes it use the caps it has in a bad way etc.
Here's the only thread I could dig up on buffer overflows in NaCL: http://permalink.gmane.org/gmane.comp.security.nativeclient....
Why would Google want to not bother applying a belt-and-braces exploit mitigation that costs 0% CPU?
But NaCL is also used to isolate "built in" embeddables e.g. Flash, which I have used as an example of a NaCL plugin that comes with chrome in both the previous posts?
Another example is the voice activation plugin that got them into so much trouble recently...
Imagine you walk past your colleagues computers saying things like "let's google something naughty" loudly...
And now let's extend that to playing an audio snippet that invokes a stack smash? :)
Are not google-bundled plugins allowed to run even when the user doesn't allow third-party NaCL plugins to run?
Its belt and braces. Why wouldn't chrome bother to enable a pass that costs 0% runtime performance? After all the money and time Google have sunk into other runtime checks like ASan, why wouldn't they also enable this?
It made me think: what other 'exploit mitigations' do Google put into NaCL, even though its sandboxed? So I quickly gooogled to see if they use ASLR inside NaCL, for example. Here's what I found:
https://code.google.com/p/nativeclient/issues/detail?id=2962
So they added ASLR, and they made a nice point:
"for the threat model where a NaCl module might process untrusted input, it would be nice to provide ASLR for the NaCl module so untrusted input won't (easily) be able to take control of the NaCl module (if/when the NaCl module has bugs). (this is a different threat model that the usual one in NaCl, where the NaCl module is untrusted. here we are trying to make sure that a NaCl module, which is executing code on the behalf of some domain/web site, isn't easily pwned, even if the NaCl runtime is itself okay.)"
By your analysis, Gmail could implement a feature that lets a sender run arbitrary JavaScript in the recipient's browser, and this would have no security impact as long as the JavaScript sandbox was not escaped. But in reality this would be a huge breach, because there are valuable things inside the sandbox that attackers should not have access to.
Put another way, this wouldn't help defend Chrome from NaCl, but it would help defend the NaCl app from it's clients. This would be in Google's interest to implement because it would make the platform more attractive to developers.
I see your point. I guess you're saying, there could be a photo editing app in which Alice can send pictures to Bob, and Mallory might send a malicious picture to Alice that coerces her client into betraying all its photos.
They might be able to apply that over all of android - and that will automatically apply over java based apps.From there it's just a matter of incentives, to rapidly create change in rest of the apps.
Here's a nice article describing it:
> This means that apps can automatically “take advantage of new processor capabilities we might be adding in the future, without you re-submitting to the store.”
http://thenextweb.com/apple/2015/06/17/apples-biggest-develo...
I play writing LLVM backends, and its entirely viable to even do things like rewrite float80 and other assumptions that a front-end has made for a particular target.
There will be ISAs sufficiently different that you cannot make bitcode generated when targetting one not be massaged to fit another, but they are not mainstream. The mainstream are all increasingly similar 64-bit targets.
It also means the end of Universal binaries as Apple can thin the compiled app for each target device.
the PPC switch over was painful, as was the 32 versus 64 bit era. They want to avoid that in the future.
Use of SIMD intrinsics are a tougher nut, but I've actually been playing with them at an IR level for hobby stuff and I declare its not intractable.
I know, I play with a hobby llvm backend that retargets.
How so? I recall it being amazingly painless.
Now they already can, technically (via fat binaries, they've already been through multiple architectural transitions), the interesting part is they could now go through these transitions without developers having to be involved.