Security/Reviews/Firefox7/ReviewNotes/AzureD2DCanvas: Difference between revisions
Jump to navigation
Jump to search
(Created page with "holding") |
No edit summary |
||
(3 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
==Items reviewed == | |||
* Azure Direct2D backend for Canvas - https://wiki.mozilla.org/Platform/Features/AzureD2DCanvas | |||
== Introduce Feature == | |||
=== Goal of Feature, what is trying to be achieved (problem solved, use cases, etc) === | |||
* canvas was on cairo then cairo on top of direct2D | |||
** this removes cairo and replaces with Azure | |||
* Azure is a thinner wrapper and alows for more efficiency and better API map up | |||
* This is Windows only | |||
** For now? | |||
** cairo will cont on other platforms | |||
** & on Win where we do D2D | |||
* Azure is an in house developed platform | |||
* New implementation will be reachable directly through existing canvas functionality -- see also https://developer.mozilla.org/en/Drawing_Graphics_with_Canvas | |||
=== What solutions/approaches were considered other than the proposed solution? === | |||
* Designed to replace cairo | |||
* http://blog.mozilla.com/joe/2011/04/26/introducing-the-azure-project/ | |||
* http://www.basschouten.com/blog1.php/comparing-performance-azure-vs-cairo | |||
=== Why was this solution chosen? === | |||
^^ see above | |||
=== Any security threats already considered in the design and why? === | |||
* does not deal with content on websites, it's really in between | |||
* no specific threats considered | |||
* there was an info leak bug in cairo direct2D, this was taken into account {{bug|655836}} | |||
== Understanding the scope of Azure project == | |||
* Canvas is (currently) the only place where Azure is a replacement. Elsewhere, it's in concert with existing code | |||
* Do we have a listing of what will using Cairo and what will using Azure (and what will using Cairo ''through'' Azure)? | |||
* No immediate plans to leave Cairo on nonD2D on windows, OS X will get Azure on top o core graphics, Linux will get Azure on top of Cairo | |||
* Fonts | |||
** Cairo doesn't really do fonts, freetype on Linux/OS X, and GDI on Win | |||
== Threat Brainstorming == | |||
* Are we more worried about bugs in Azure itself, or in exposing OS APIs to attack that had previously been protected by API layers atop them (e.g. stateful or range-checking)? | |||
** both, right? | |||
** more worried about bugs in the new canvas implementation | |||
* Sec problems in D2D may be easier to exploit than previously as some of the layers are not there | |||
** Would these problems be specific to graphics cards or drivers? What kind of testing matrix do we need? | |||
*** More likely to be bugs in D2D itself | |||
* Numerical thresholds? | |||
** Not many around pixels. Some around arcs. | |||
** Mostly floating point (in contrast to cairo which was mostly int), in part because D2D takes floats as input | |||
*** The usual float concerns: NaN, Infinity, positive and negative zero, denorm, lost precision | |||
* Does the Azure API impose limits on the size being passed? (i.e. a very large image, larger than say the screen size) | |||
** No | |||
* What do you do when D2D returns errors? | |||
** Hopefully we don't draw it | |||
** Hopefully we don't draw uninitialized memory onto the screen | |||
** Hopefully we don't stop drawing the entire browser | |||
** Behavior here should be verified | |||
** D2D is restricted by texture size limits that are imposed by the graphics card | |||
*** Normally fail if you try to create/render above limits | |||
**** But then we fall back to a software (cairo) surface rather than giving up entirely | |||
** We should only get errors from D2D upon canvas creation (e.g. OOM), not upon drawing crazy shapes | |||
*** Do we have assertions to verify this? | |||
* What happens when you resize a canvas? | |||
** Especially when you pass the size threshold while resizing? | |||
*** And JS still has reference to a 2dcontext object? | |||
** Contents are lost? | |||
* What happens when you stretch the display of a canvas? | |||
** Not a big deal, basically goes through image-resize code. | |||
== Conclusions / Action Items == | |||
* [bsterne] Fuzz canvas on top of Azure as a general fuzzing task | |||
** Especially radial gradients and fuzzy shadows, since those are things "done by Azure" rather than just passed to D2D | |||
** Is it stateless all the way down? Or does fuzzing need to take some kind of state into account? | |||
*** Clipping is stateful. We'll often take different code paths depending on whether there's a clip or not. | |||
** We have a few canvas fuzzers in the private fuzzing repo | |||
** Do we have existing canvas tests in our test suite? Could be used for mutation fuzzing (mutate JavaScript that modifies canvas objects) | |||
*[jeff] {{bug|679868}}Add assertions to verify that D2D does not return errors except upon canvas creation | |||
* [QA?] Make sure we have regression tests for many of the questions above (e.g. what happens if you resize a canvas from tiny to huge and then reuse a 2dcontext JS object) | |||
*[curtisk] QA contact? Talk to Juan/Matt about the QA Lead about using items in this review to build test cases | |||
** {2011.08.19} Talked to Matt, Andrei is a contractor, they will use our notes to build test cases and get back to us to review them | |||
[[Category:SecReview|AzureD2DCanvas]] |
Latest revision as of 19:33, 4 January 2012
Items reviewed
- Azure Direct2D backend for Canvas - https://wiki.mozilla.org/Platform/Features/AzureD2DCanvas
Introduce Feature
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
- canvas was on cairo then cairo on top of direct2D
- this removes cairo and replaces with Azure
- Azure is a thinner wrapper and alows for more efficiency and better API map up
- This is Windows only
- For now?
- cairo will cont on other platforms
- & on Win where we do D2D
- Azure is an in house developed platform
- New implementation will be reachable directly through existing canvas functionality -- see also https://developer.mozilla.org/en/Drawing_Graphics_with_Canvas
What solutions/approaches were considered other than the proposed solution?
- Designed to replace cairo
- http://blog.mozilla.com/joe/2011/04/26/introducing-the-azure-project/
- http://www.basschouten.com/blog1.php/comparing-performance-azure-vs-cairo
Why was this solution chosen?
^^ see above
Any security threats already considered in the design and why?
- does not deal with content on websites, it's really in between
- no specific threats considered
- there was an info leak bug in cairo direct2D, this was taken into account bug 655836
Understanding the scope of Azure project
- Canvas is (currently) the only place where Azure is a replacement. Elsewhere, it's in concert with existing code
- Do we have a listing of what will using Cairo and what will using Azure (and what will using Cairo through Azure)?
- No immediate plans to leave Cairo on nonD2D on windows, OS X will get Azure on top o core graphics, Linux will get Azure on top of Cairo
- Fonts
- Cairo doesn't really do fonts, freetype on Linux/OS X, and GDI on Win
Threat Brainstorming
- Are we more worried about bugs in Azure itself, or in exposing OS APIs to attack that had previously been protected by API layers atop them (e.g. stateful or range-checking)?
- both, right?
- more worried about bugs in the new canvas implementation
- Sec problems in D2D may be easier to exploit than previously as some of the layers are not there
- Would these problems be specific to graphics cards or drivers? What kind of testing matrix do we need?
- More likely to be bugs in D2D itself
- Would these problems be specific to graphics cards or drivers? What kind of testing matrix do we need?
- Numerical thresholds?
- Not many around pixels. Some around arcs.
- Mostly floating point (in contrast to cairo which was mostly int), in part because D2D takes floats as input
- The usual float concerns: NaN, Infinity, positive and negative zero, denorm, lost precision
- Does the Azure API impose limits on the size being passed? (i.e. a very large image, larger than say the screen size)
- No
- What do you do when D2D returns errors?
- Hopefully we don't draw it
- Hopefully we don't draw uninitialized memory onto the screen
- Hopefully we don't stop drawing the entire browser
- Behavior here should be verified
- D2D is restricted by texture size limits that are imposed by the graphics card
- Normally fail if you try to create/render above limits
- But then we fall back to a software (cairo) surface rather than giving up entirely
- Normally fail if you try to create/render above limits
- We should only get errors from D2D upon canvas creation (e.g. OOM), not upon drawing crazy shapes
- Do we have assertions to verify this?
- What happens when you resize a canvas?
- Especially when you pass the size threshold while resizing?
- And JS still has reference to a 2dcontext object?
- Contents are lost?
- Especially when you pass the size threshold while resizing?
- What happens when you stretch the display of a canvas?
- Not a big deal, basically goes through image-resize code.
Conclusions / Action Items
- [bsterne] Fuzz canvas on top of Azure as a general fuzzing task
- Especially radial gradients and fuzzy shadows, since those are things "done by Azure" rather than just passed to D2D
- Is it stateless all the way down? Or does fuzzing need to take some kind of state into account?
- Clipping is stateful. We'll often take different code paths depending on whether there's a clip or not.
- We have a few canvas fuzzers in the private fuzzing repo
- Do we have existing canvas tests in our test suite? Could be used for mutation fuzzing (mutate JavaScript that modifies canvas objects)
- [jeff] bug 679868Add assertions to verify that D2D does not return errors except upon canvas creation
- [QA?] Make sure we have regression tests for many of the questions above (e.g. what happens if you resize a canvas from tiny to huge and then reuse a 2dcontext JS object)
- [curtisk] QA contact? Talk to Juan/Matt about the QA Lead about using items in this review to build test cases
- {2011.08.19} Talked to Matt, Andrei is a contractor, they will use our notes to build test cases and get back to us to review them