[webkit-dev] WebCL Release

[Tasneem Brutch - Samsung]

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

My apologies for the misinterpretation.  What I meant to state in my
previous email was that WebCL would be behind a compile time flag, and
developers would need to explicitly turn it on.  At a later time, only
after the completion of the WebCL specification, and after the security
issues have been addressed, would this be changed.

> 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?

Your understanding is correct.  As the WebCL standard gets defined, it
will be addressed in the specification, through collaboration with the
OpenCL driver vendors. 

> does the WebCL WG have a table of attack surfaces and hardening
solutions that have been taken?

A discussion on the security aspects of WebCL is currently in progress
in the WebCL working group.  The working group is working on identifying
the issues, defining solutions and providing recommendations to OpenCL
driver vendors and hardware vendors, where needed.

I would also like to note that there is an updated version of Samsung's
WebCL prototype, which can be found at http://code.google.com/p/webcl/.
This has been tested with WebKit r92365, on MacOS 10.7.

Regards,
Tasneem

-----Original Message-----
From: Oliver Hunt [mailto:oliver at apple.com] 
Sent: Wednesday, August 24, 2011 4:00 PM
To: Tasneem Brutch - Samsung
Cc: webkit-dev at lists.webkit.org; Won Jeon - SISA; Simon Gibbs - Samsung
Subject: Re: [webkit-dev] WebCL Release


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