Re: Hypothetical ? concerning LuaJIT, iOS, and consoles.

  • From: Coda Highland <chighland@xxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Sun, 20 Sep 2015 19:52:47 -0700

On Sun, Sep 20, 2015 at 4:56 PM, Lance Thornblad
<lance.thornblad@xxxxxxxxx> wrote:


Oh, I was under the impression it was a security restriction that could
be
gotten around on jail-broken iOS devices. What you're describing -
wouldn't
that also restrict native applications?

iOS doesn't enforce W^X at the OS level -- Safari itself uses a JIT.
(And until recently, third-party apps couldn't even get Javascript JIT
in embedded web views -- Apple finally got off their butts to allow
that.) Apple enforces it through the App Store approvals process.


But until they do "get off their butts," I'm curious as to whether it would
be possible to generate a .o (or whatever the iOS equivalent is) and link it
at the OS level..?

iOS uses .o files, yes, but no, there's no way to do that in LuaJIT --
because it's a trace compiler, when LuaJIT compiles a piece of code,
it compiles it with assumptions based on the current runtime state. It
also uses the fully-resolved addresses of functions and data instead
of generating relocatable code.

Anyway, Apple's pretty unlikely to allow dynamic code generation on
iOS. They consider it too much of a threat to their security model and
to their monetization scheme. The only reason they enabled it for
Javascript is because they can control the Javascript VM
implementation and keep it sandboxed away from app code.

Anyway, when it comes down to it, LuaJIT's interpreter mode is still
quite fast (especially if the JIT is disabled) and you can still use
the Lua C API for integrating with the host process. User-generated
content shouldn't suffer too badly, especially if the UGC is just
controlling things at a high level and delegating the heavy lifting to
host-provided APIs.

/s/ Adam

Other related posts:

  1. Home
  2. luajit
  3. Archive
  4. 09-2015