Firefox3.1/JS Tracing Security Review

Overview

Adds a just-in-time native code compiler for JavaScript.

What security issues do you address in your project?
- Tracing is intended to be security-neutral, and produce the same results as without tracing, only faster.
Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
- No; tracing is not controlled through external resources other than the base preference to enable it for content or chrome.
Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
- Writable memory allocated and executed at runtime may be a target for writing via other attack vectors.
- Manifest constants are in some cases derived from the execution of script and embedded in the generated code; this may make it easier for attackers to control the contents of executable memory as part of an attack.
- We assume that existing security infrastructure (wrappers and privilege/capability checks) are effective when called under trace; this requires care that the frame-walking assumptions of the wrappers and principals can handle frames being omitted in some cases.

Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
- There is no new content- or extension-exposed API provided. SpiderMonkey embedders will have at least one new API, to control enabling/disabling the JIT, and there may be additional API additions to support additional tracing hints t
Does it interoperate with a web service? How will it do so?
Explain the significant file formats, names, syntax, and semantics.
Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?
Does it change any existing interfaces?

The tracer operates on JavaScript bytecode produced by the Mozilla JS engine (not imported from other locations)
What data is read or parsed by this feature

What failure modes or decision points are presented to the user?
Can its files be corrupted by failures? Does it clean up any locks/files after crashes?

Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?
- There are hidden prefs to enable/disable the JIT.
  - javascript.options.jit.chrome
  - javascript.options.jit.content
Are there build options for developers? [#ifdefs, ac_add_options, etc.]
- --disable-jit (?)
What ranges for the tunable are appropriate? How are they determined?
What are its on-going maintenance requirements (e.g. Web links, perishable data files)?

Are there related projects in the community?

If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?
Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose?

nanoJIT needs a separate security review (probably code-level review)
- out of memory conditions in particular
GC has been largely disconnected from tracing: if GC happens while we're recording we keep recording (so nothing is interrupted when it's not expecting it) but we throw away the trace.
main attack would be getting us to generate dangerous code.
- code cache
- LIR cache
could generated code access DOM objects that interpreted code would not be allowed?
multi-threaded doesn't work with shared globals -- native/interpreted or two native threads using the same variables would have their own copies. We currently disallow this.
Need Jason's patch to land, can create corner cases where we mishandle builtins