3 ms·

Now we just need to wait for Apple to allow the JIT on iOS. Could only take a few more years guys! (Of course having the JIT on Android, Raspberry-Pi and other

Now we just need to wait for Apple to allow the JIT on iOS. Could only take a few more years guys! (Of course having the JIT on Android, Raspberry-Pi and other ARM devices is a huge plus. I'm just frustrated by Apple's paranoia.)

justincormack 13y ago
Hardly "now" - there are ongoing complaints re other JITs, eg LuaJIT, not to mention Javascript... But on the other hand, non executable heap is a reasonably valid defence against some attack types. And Apple don't care about your convenience...
- mikeash 13y ago
  Non-executable heap is an extremely reasonable default, but not even allowing you to mprotect() a page back to being executable is just annoying.
  - nezza-_- 13y ago
    It actually makes a lot of sense. Preventing pages from being executable makes exploitation so so so much harder... Because you will need to do ROP (Return oriented programming) and Apple is quite good at ASLR (Address space layour randomization).. It also means that malware can't just load external code from a C&C server etc.. And yes, it sucks that all this means that one can't JIT. Edit: Allowing executable pages would also break mandatory code signing.
    - mikeash 13y ago
      You'll have to do ROP to get the app to make your data executable anyway. Is it really that much easier?
- pjmlp 13y ago
  > , not to mention Javascript... JavaScript support has been improved on the upcoming iOS version, even interaction with the Objective-C runtime. Not sure about JIT, though. If you have an Apple account check the JavaScript sessions from WWDC 2013.
  - fijal 13y ago
    it's apple-approved javascript which does not have the same restrictions as normal stuff.
    - pjmlp 13y ago
      Yes, but that makes JavaScript one less language to complain about in iOS.
      - fijal 13y ago
        no, because you can't challenge "javascript is slow", since only apple is allowed to JIT it. If they do a bad job, there is noone else to help.
        pjmlp 13y ago
        Yes there is, you can always write a native compiler for JavaScript, no one says you need to JIT it. Lisp, Dylan are just two examples from dynamic languages with native compilers.
pudquick 13y ago
Unfortunately, JIT will never be allowed on iOS because it invalidates the security model of the iOS App Store. The current security model requires that all iOS App Store executables are monolithic - with the only exception being Apple-provided Apple-allowed dynamic libraries. You cannot publish an iOS App Store app that includes separate third-party dynamic libraries - they have to be statically linked into the final executable, which Apple then encrypts during the signature process. This allows Apple to have 100% vetting control over the native code published in their iOS App Store. You can't side load unsigned code / code they haven't seen. There was actually an exploit / proof of concept where someone published a financial app in the App Store that called home and loaded arbitrary bytes into executable memory. The bug was patched and the developer was banned from the App Store. A JIT would effectively allow the same thing: arbitrary native code execution on an iOS device that isn't part of an executable Apple has seen / signed. However! This does not mean python is unavailable in the App Store. Python for iOS, Pythonista (my favorite), and several other flavors of interpreter already exist. It's just that they're bytecode interpreters only - no JIT allowed. And any attempts to use ctypes to dynamically load a module actually triggers a segfault (it's an intentional part of the iOS dynamic linker that does this - segfaults loading anything non-standard). So go ahead and enjoy python on iOS - just don't hold your breath waiting for JIT.
coldtea 13y ago
>I'm just frustrated by Apple's paranoia Paranoia? http://thenextweb.com/insider/2013/06/26/juniper-mobile-malware-is-an-increasingly-profit-driven-business-as-92-of-all-known-threats-target-android/ http://thenextweb.com/insider/2013/06/26/juniper-mobile-malw...

justincormack 13y ago

Hardly "now" - there are ongoing complaints re other JITs, eg LuaJIT, not to mention Javascript... But on the other hand, non executable heap is a reasonably valid defence against some attack types. And Apple don't care about your convenience...

mikeash 13y ago
Non-executable heap is an extremely reasonable default, but not even allowing you to mprotect() a page back to being executable is just annoying.
- nezza-_- 13y ago
  It actually makes a lot of sense. Preventing pages from being executable makes exploitation so so so much harder... Because you will need to do ROP (Return oriented programming) and Apple is quite good at ASLR (Address space layour randomization).. It also means that malware can't just load external code from a C&C server etc.. And yes, it sucks that all this means that one can't JIT. Edit: Allowing executable pages would also break mandatory code signing.
  - mikeash 13y ago
    You'll have to do ROP to get the app to make your data executable anyway. Is it really that much easier?
pjmlp 13y ago
> , not to mention Javascript... JavaScript support has been improved on the upcoming iOS version, even interaction with the Objective-C runtime. Not sure about JIT, though. If you have an Apple account check the JavaScript sessions from WWDC 2013.
- fijal 13y ago
  it's apple-approved javascript which does not have the same restrictions as normal stuff.
  - pjmlp 13y ago
    Yes, but that makes JavaScript one less language to complain about in iOS.
    - fijal 13y ago
      no, because you can't challenge "javascript is slow", since only apple is allowed to JIT it. If they do a bad job, there is noone else to help.
      - pjmlp 13y ago
        Yes there is, you can always write a native compiler for JavaScript, no one says you need to JIT it. Lisp, Dylan are just two examples from dynamic languages with native compilers.

pudquick 13y ago

Unfortunately, JIT will never be allowed on iOS because it invalidates the security model of the iOS App Store. The current security model requires that all iOS App Store executables are monolithic - with the only exception being Apple-provided Apple-allowed dynamic libraries. You cannot publish an iOS App Store app that includes separate third-party dynamic libraries - they have to be statically linked into the final executable, which Apple then encrypts during the signature process. This allows Apple to have 100% vetting control over the native code published in their iOS App Store. You can't side load unsigned code / code they haven't seen. There was actually an exploit / proof of concept where someone published a financial app in the App Store that called home and loaded arbitrary bytes into executable memory. The bug was patched and the developer was banned from the App Store. A JIT would effectively allow the same thing: arbitrary native code execution on an iOS device that isn't part of an executable Apple has seen / signed. However! This does not mean python is unavailable in the App Store. Python for iOS, Pythonista (my favorite), and several other flavors of interpreter already exist. It's just that they're bytecode interpreters only - no JIT allowed. And any attempts to use ctypes to dynamically load a module actually triggers a segfault (it's an intentional part of the iOS dynamic linker that does this - segfaults loading anything non-standard). So go ahead and enjoy python on iOS - just don't hold your breath waiting for JIT.

coldtea 13y ago

>I'm just frustrated by Apple's paranoia Paranoia? http://thenextweb.com/insider/2013/06/26/juniper-mobile-malware-is-an-increasingly-profit-driven-business-as-92-of-all-known-threats-target-android/ http://thenextweb.com/insider/2013/06/26/juniper-mobile-malw...