4 ms·

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 like

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.

coldtea 11y ago
>Google will be able to do likewise for NaCL apps All 5 of them?
minthd 11y ago
>>Google will be able to do likewise for NaCL apps. 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.
higherpurpose 11y ago
Apple is making its apps LLVM-based now? Doesn't that mean they could soon push for ARM CPUs in Mac OS, too?
- willvarfar 11y ago
  It means exactly that. 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-developer-news-at-wwdc-that-nobodys-talking-about-bitcode/ http://thenextweb.com/apple/2015/06/17/apples-biggest-develo...
  - vsl 11y ago
    It doesn't. Bitcode is arch specific and unportable. It allows some instruction-set level optimizations, but not changing e.g. endianness (exactly what x64 and arm differ in) or type sizes.
    - willvarfar 11y ago
      ARM cores, although technically bi-endian, are in practice little-endian. 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.
      - jakobegger 11y ago
        But what about things like non-aligned memory access (allowed on x86, not allowed on ARM)? Porting code across architectures can't be as easy as just swapping LLVM backends, when not even recompiling the code is sufficient.
        willvarfar 11y ago
        Modern ARMs are just fine with unaligned access. 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.
- crucialfelix 11y ago
  yes. developers will be able to submit apps as LLVM Bitcode which means that Apple can switch to ARM for some new device and recompile the app without the developer having to resubmit it. 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.
  - pg314 11y ago
    At the moment LLVM bit code generated by Clang is still architecture dependent (e.g. sizeof() still generates code that depends on the architecture).
    - willvarfar 11y ago
      But modern CPUs are all converging on 64-bits, for example. 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.
      - mappu 11y ago
        Converging on 64-bit CPUs doesn't mean converging on standard `sizeof()` values (c.f. windows x86_64 ABI is LLP64 but linux x86_64 ABI is LP64)
        willvarfar 11y ago
        It's easy to loose sight of the fact that we are talking about 64bit OS X here... The diff between ir that targeted x86-64 and arm64 and so on is something Apple has some control over. I know, I play with a hobby llvm backend that retargets.
    - crucialfelix 11y ago
      true, I didn't mean that it would solve a future 32 v 64 problem.
  - 11y ago
- masklinn 11y ago
  Or, the other way around, for x86_64 in mobile devices. 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.
- Alphasite_ 11y ago
  No, bit odd is too low level for this and I believe it's only used for iOS apps ATM.
tptacek 11y ago
Should Google bother? The point of NaCL apps is that memory corruption flaws in them aren't supposed to matter.
- willvarfar 11y ago
  Well bother business-wise? I mostly included them for completeness. I'm a bit fan of PNaCL but its not really taken off. 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.general/6 http://permalink.gmane.org/gmane.comp.security.nativeclient....
  - tptacek 11y ago
    It's not that they're better sandboxed; it's that regardless of whether memory corruption exploits work, in the NaCL security model, if the sandbox doesn't work, you're fucked regardless. So why bother with hardened runtimes?
    - willvarfar 11y ago
      The buffer overflow in NaCL extension that comes with Chrome e.g. Flash may be just the a stepping stone in a Pwnium entry that escapes the sandbox through yet another webGL validation bug or something. Why would Google want to not bother applying a belt-and-braces exploit mitigation that costs 0% CPU?
      - tptacek 11y ago
        You're not following my point. NaCL programs are content-controlled. Attackers start out with arbitrary code execution.
TD-Linux 11y ago
>Google will be able to do likewise for NaCL apps. No they won't, because NaCl is native x86. Unless you mean PNaCl, which is a different technology with much less adoption than NaCl.

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.

coldtea 11y ago

>Google will be able to do likewise for NaCL apps All 5 of them?

minthd 11y ago

>>Google will be able to do likewise for NaCL apps. 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.

higherpurpose 11y ago

Apple is making its apps LLVM-based now? Doesn't that mean they could soon push for ARM CPUs in Mac OS, too?

willvarfar 11y ago
It means exactly that. 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-developer-news-at-wwdc-that-nobodys-talking-about-bitcode/ http://thenextweb.com/apple/2015/06/17/apples-biggest-develo...
- vsl 11y ago
  It doesn't. Bitcode is arch specific and unportable. It allows some instruction-set level optimizations, but not changing e.g. endianness (exactly what x64 and arm differ in) or type sizes.
  - willvarfar 11y ago
    ARM cores, although technically bi-endian, are in practice little-endian. 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.
    - jakobegger 11y ago
      But what about things like non-aligned memory access (allowed on x86, not allowed on ARM)? Porting code across architectures can't be as easy as just swapping LLVM backends, when not even recompiling the code is sufficient.
      - willvarfar 11y ago
        Modern ARMs are just fine with unaligned access. 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.
crucialfelix 11y ago
yes. developers will be able to submit apps as LLVM Bitcode which means that Apple can switch to ARM for some new device and recompile the app without the developer having to resubmit it. 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.
- pg314 11y ago
  At the moment LLVM bit code generated by Clang is still architecture dependent (e.g. sizeof() still generates code that depends on the architecture).
  - willvarfar 11y ago
    But modern CPUs are all converging on 64-bits, for example. 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.
    - mappu 11y ago
      Converging on 64-bit CPUs doesn't mean converging on standard `sizeof()` values (c.f. windows x86_64 ABI is LLP64 but linux x86_64 ABI is LP64)
      - willvarfar 11y ago
        It's easy to loose sight of the fact that we are talking about 64bit OS X here... The diff between ir that targeted x86-64 and arm64 and so on is something Apple has some control over. I know, I play with a hobby llvm backend that retargets.
  - crucialfelix 11y ago
    true, I didn't mean that it would solve a future 32 v 64 problem.
- 11y ago
masklinn 11y ago
Or, the other way around, for x86_64 in mobile devices. 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.
Alphasite_ 11y ago
No, bit odd is too low level for this and I believe it's only used for iOS apps ATM.

tptacek 11y ago

Should Google bother? The point of NaCL apps is that memory corruption flaws in them aren't supposed to matter.

willvarfar 11y ago
Well bother business-wise? I mostly included them for completeness. I'm a bit fan of PNaCL but its not really taken off. 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.general/6 http://permalink.gmane.org/gmane.comp.security.nativeclient....
- tptacek 11y ago
  It's not that they're better sandboxed; it's that regardless of whether memory corruption exploits work, in the NaCL security model, if the sandbox doesn't work, you're fucked regardless. So why bother with hardened runtimes?
  - willvarfar 11y ago
    The buffer overflow in NaCL extension that comes with Chrome e.g. Flash may be just the a stepping stone in a Pwnium entry that escapes the sandbox through yet another webGL validation bug or something. Why would Google want to not bother applying a belt-and-braces exploit mitigation that costs 0% CPU?
    - tptacek 11y ago
      You're not following my point. NaCL programs are content-controlled. Attackers start out with arbitrary code execution.

TD-Linux 11y ago

>Google will be able to do likewise for NaCL apps. No they won't, because NaCl is native x86. Unless you mean PNaCl, which is a different technology with much less adoption than NaCl.