Firefox3.1/JS Tracing Security Review

Overview

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

Background links

• summit session description
• land on m-c: bug 449436; regressions with JIT enabled bug 451602

Security and Privacy

• 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.

Exported APIs

• 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?

Module interactions

• What other modules are used (REQUIRES in the makefile, interfaces)

Data

• 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 is the output of this feature
• What storage formats are used

Reliability

• 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?

Configuration

• 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)?

Relationships to other projects

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?

Review comments

• nanoJIT needs a separate security review
• 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.
• 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