[webkit-dev] WebCL Release

[Oliver Hunt]

On Aug 24, 2011, at 3:20 PM, Tasneem Brutch - Samsung wrote:

> Khronos WebCL is not yet a specification, and the WebCL API has not yet been standardized.  The WebCL members are currently discussing the security and interoperability issues in the WebCL Working Group.  Samsung would like to introduce a WebCL patch at this time, to follow the ongoing specification activity in the Khronos WebCL working group.
>  
> WebCL would not be enabled in the browser by default, and users will have the choice to enable it in the browser.

That's not really a great consolation -- defining a spec where there's is the assumption it will be disabled by default doesn't seem like a good plan in the long term.  In all honesty "disabled by default" is only a bit better than "asking the user's permission" in terms of security.

> The WebGL security concerns previously raised, related to the following aspects:
>  
> 1) Cross domain image access  - timed loop attack.
> 2) Issues related to general hardening.
>  
> In response to item 1), WebGL and HTML specs have been updated, mandating CORS (Cross Origin Resource Sharing) for video, images and audio, and servers have to grant cross domain access to media resources.
> Item 2) was addressed by the WebGL working group, through ARB_ROBUSTNESS extensions, which provide additional protection being mandated.  The new robustness specification limits the side-effects of a GPU reset after a Denial of Service attack.  In addition the ANGLE shader validator was improved. 

The hardening policies for WebGL work because WebGL is built on a heavily restricted version of GLSL.  My understanding was that OpenCL had access to pointers and arrays provided by the host application, but did not guarantee memory safety.  Given all kernels provided to WebCL are untrusted code that is clearly unsafe, to what extent does the WebCL spec (or draft spec as the case may be) limit illegal memory operations?

ARB_ROBUSTNESS is specifically a GPU flag (mostly needed due to the absence of any memory protection on GPU), but one of the goals of OpenCL was to provide a uniform interface to CPU and GPU compute resources so is not particularly relevant to the discussion of WebCL security.

Now I will say I have no real development experience with OpenCL (essentially I have read the documentation and looked at the pretty demos), but it is my understanding that I can provide OpenCL with a specific piece of memory, in WebCL I assume an ArrayBuffer or similar,  and then the kernel can compute an arbitrary index into that storage -- is that understanding correct?  If so how does WebCL ensure that this behaviour is safe?

> In the short term, browser vendors would maintain white and black lists, so that the compromised system can have WebGL disabled until mitigation is developed.  In the longer term, GPUs would provide increasingly robust security and tasking, to allow GPU to become a first-class computing platform alongside CPU.
As I said above WebGL already introduces a large number of restrictions on the possible operations performed by a shader _without_ any support from the ARB_ROBUSTNESS.  OpenCL however explicitly allows a lot of the memory access that WebGL deliberately prevents.

> As the WebCL standardization effort progresses, the WebCL API would be defined with security as the highest priority, with provisions for both short term, and longer term security and robustness solutions, similar to the approach taken by the WebGL working group.

WebGL deliberately removed a number of features, and introduced a range of type safety requirements not originally present in GLES, does the WebCL WG have a table of attack surfaces and hardening solutions that have been taken?

--Oliver