Brandon's Notes

General

• potential DoS by sending large job to shader
• user-space version of the driver compiles the shader and passes to the GPU
• jeff: if you own the firefox process you could make the compiler do things it doesn't expect
• vlad: when you're on the GPU, you're fairly limited as to what you can do
• driver supplies the compiler (runs as user)
• driver implements OpenGL (not OS)
• all GL calls are pipelined, very few have a return value
• vlad: it would be a good idea to create a GL context noop to do more robust OOVM testing
• GL context tied only to canvas element, NOT the document

Top threats

• GLSL compiler bugs
• DoS bugs, e.g. on Mac

Lucas Notes

General

Shader program consumes inputs (vertices, etc), state (operations), resources (textures, etc)

steps: 1) Assemble shader 2) Compile shader 3) call, query, etc shader

UBO (uniform buffer object) API - main API for accessing shaders, drawing operations, etc

Typed Arrays - for defining data delivered to webGL

Newer drivers have defined behaviors (thanks to DirectX) for reading/writing out of bounds, etc. Older drivers.. not so much. Also proposed as extension to openGL: ARB_robustness.

No direct access to gfx card buffers and APIs. All access indirect (via opaque handles associated with specific webgl context, etc)

Do we detect content-created xpcom objects masquerading as handles?

No access to things outside the content area (in theory), enforce by our implementation

Buffers are zeroed at allocation.

OpenGL always renders offscreen. We render to canvas (visible screen).

ANGLE tries to limit GLSL to valid and Mozilla supported syntax (and limit general sanity of variable names/lengths), but for the most part we just hand over the GLSL to the card.

Once a program is handed over it runs until completion, so there's no way of controlling the runtime... so potential DoS vectors. Windows 7 and Vista have a GFX watchdog so they will kill and recover. On other platforms including OS X the OS will slow down to the point of being unusable (killing the app doesn't necessarily prevent ongoing shader execution)

webGL about:config pref but no settings panel. Hardware acceleration settings is not related (turning one off doesn't affect the other). There are separate blacklists for webGL and hardware accel.

Shaders are run by the GPU not driver. Shaders are compiled in userland by the user-side of the driver (within our process)

All openGL calls are pipelined.. very few have a return value.

GL resources are torn down once parent canvas element is GC'd or otherwise destroyed.

Lots of weird bugs in OS X esp 10.5, will probably be blocklisted

1) ANGLE GLSL validation & translation of GL(e?)SL to full openGL on all platforms 2) ANGLE on windows is used as translation of GLSL to directx9. Developed and maintained by transgaming on contract to Google (how do we get accountability and responsiveness to security bugs from transgaming?)

Remote kill switch for webGL for specific or all drivers via nightly pings.

Top threats

1) bugs in shader compilation and execution

2) denial of service for runaway processes (esp on Macs)... if it consumes enough resources it could introduce other bugs such as data theft

3) maintenance and accountability for bugs in ANGLE (get a support contract in place)

Be aggressive about naming and shaming about driver bugs (i.e. if no response from developer in 1 week then block and post on security blog).