Firefox3.1/JS Tracing Security Review

From MozillaWiki
Jump to: navigation, search


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

Background links

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)


  • 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


  • 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.content
  • Are there build options for developers? [#ifdefs, ac_add_options, etc.]
  • 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 (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