Firefox3.1/JS Tracing Security Review: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(New page: == Overview == ''Adds a just-in-time native code compiler for JavaScript.'' ;Background links * [http://wiki.mozilla.org/Summit2008/Sessions/Proposals/Tamarin_Tracing_JIT_Intro summit ses...)
 
Line 40: Line 40:
== Configuration ==
== Configuration ==
* Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?
* 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.]
* Are there build options for developers? [#ifdefs, ac_add_options, etc.]
** [https://bugzilla.mozilla.org/show_bug.cgi?id=463172 --disable-jit (?)]
* What ranges for the tunable are appropriate? How are they determined?
* 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)?
* What are its on-going maintenance requirements (e.g. Web links, perishable data files)?

Revision as of 19:33, 13 January 2009

Overview

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)

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