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

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Reply via email to