Re: [webkit-dev] WebCL Release
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:oli...@apple.com] Sent: Wednesday, August 24, 2011 4:00 PM To: Tasneem Brutch - Samsung Cc: webkit-dev@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
[webkit-dev] WebCL Release
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. 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. 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 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. Regards, Tasneem Brutch Chair WebCL Working Group - Oliver Hunt oliver at apple.com mailto:webkit-dev%40lists.webkit.org?Subject=Re%3A%20%5Bwebkit-dev%5D%2 0WebCL%20ReleaseIn-Reply-To=%3C9A9CE4E9-38EE-446A-8940-5CC0C21C008D%40a pple.com%3E Tue Jul 5 10:53:19 PDT 2011 * Previous message: [webkit-dev] WebCL Release https://lists.webkit.org/pipermail/webkit-dev/2011-July/017471.html * Next message: [webkit-dev] JavaScriptCore on Android https://lists.webkit.org/pipermail/webkit-dev/2011-July/017454.html * Messages sorted by: [ date ] https://lists.webkit.org/pipermail/webkit-dev/2011-July/date.html#17472 [ thread ] https://lists.webkit.org/pipermail/webkit-dev/2011-July/thread.html#174 72 [ subject ] https://lists.webkit.org/pipermail/webkit-dev/2011-July/subject.html#17 472 [ author ] https://lists.webkit.org/pipermail/webkit-dev/2011-July/author.html#174 72 How has the WebCL spec dealt with the inherent security problems of OpenCL in the face of untrusted content? In the WebGL working group we spent a lot of time working on how to adequately restrict GLSL|ES to prevent security vulnerabilities, and I haven't really heard anything about what approach the WebCL WG has been taking. My concern is that OpenCL is far less restrictive than GLSL, and yet we had to clamp down on what was possible even then. --Oliver On Jul 5, 2011, at 10:41 AM, Won Jeon wrote: Dear Simon, Thanks for your interest in our WebCL prototype in WebKit. Currently, it's integrated with WebKit r78407 and hasn't been checked with WebKit's coding style guidelines. It's tested on Mac with Nvidia GPU which supports OpenCL support. Updating the code to a newer WebKit and Porting the code to other platforms should be straightforward because the only platform-dependent part is OpenCL support. WebGL is not needed for WebCL itself, but it would be better for interoperability between WebCL and WebGL, so that's why we started this work on Mac first. Regards, Won -Original Message- From: Simon Fraser [mailto:simon.fraser at apple.com http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ] Sent: Tuesday, July 05, 2011 8:12 AM To: Gyuyoung Kim Cc: webkit-dev at lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ; Simon Gibbs; Won Jeon - SISA; jinwoo7.song at samsung.com http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev Subject: Re: [webkit-dev] WebCL Release On Jul 3, 2011, at 6:28 PM, Gyuyoung Kim wrote: Hello WebKit Developers, Samsung has just open sourced an implementation of WebCL for WebKit. This is a prototype of a proposed WebCL standard that aims to define JavaScript APIs for OpenCL. The code is located at http://code.google.com/p/webcl/ and some demo videos at http://www.youtube.com/user/SamsungSISA. We're interested in any feedback on the prototype and how it can be better integrated with WebKit. Perhaps you can summarize here how it works now, and what directions you see for closer integration with WebKit? Simon ___ webkit-dev mailing list webkit-dev
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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebCL Release
On Jul 3, 2011, at 6:28 PM, Gyuyoung Kim wrote: Hello WebKit Developers, Samsung has just open sourced an implementation of WebCL for WebKit. This is a prototype of a proposed WebCL standard that aims to define JavaScript APIs for OpenCL. The code is located at http://code.google.com/p/webcl/ and some demo videos at http://www.youtube.com/user/SamsungSISA. We're interested in any feedback on the prototype and how it can be better integrated with WebKit. Perhaps you can summarize here how it works now, and what directions you see for closer integration with WebKit? Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebCL Release
Dear Simon, Thanks for your interest in our WebCL prototype in WebKit. Currently, it's integrated with WebKit r78407 and hasn't been checked with WebKit's coding style guidelines. It's tested on Mac with Nvidia GPU which supports OpenCL support. Updating the code to a newer WebKit and Porting the code to other platforms should be straightforward because the only platform-dependent part is OpenCL support. WebGL is not needed for WebCL itself, but it would be better for interoperability between WebCL and WebGL, so that's why we started this work on Mac first. Regards, Won -Original Message- From: Simon Fraser [mailto:simon.fra...@apple.com] Sent: Tuesday, July 05, 2011 8:12 AM To: Gyuyoung Kim Cc: webkit-dev@lists.webkit.org; Simon Gibbs; Won Jeon - SISA; jinwoo7.s...@samsung.com Subject: Re: [webkit-dev] WebCL Release On Jul 3, 2011, at 6:28 PM, Gyuyoung Kim wrote: Hello WebKit Developers, Samsung has just open sourced an implementation of WebCL for WebKit. This is a prototype of a proposed WebCL standard that aims to define JavaScript APIs for OpenCL. The code is located at http://code.google.com/p/webcl/ and some demo videos at http://www.youtube.com/user/SamsungSISA. We're interested in any feedback on the prototype and how it can be better integrated with WebKit. Perhaps you can summarize here how it works now, and what directions you see for closer integration with WebKit? Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebCL Release
How has the WebCL spec dealt with the inherent security problems of OpenCL in the face of untrusted content? In the WebGL working group we spent a lot of time working on how to adequately restrict GLSL|ES to prevent security vulnerabilities, and I haven't really heard anything about what approach the WebCL WG has been taking. My concern is that OpenCL is far less restrictive than GLSL, and yet we had to clamp down on what was possible even then. --Oliver On Jul 5, 2011, at 10:41 AM, Won Jeon wrote: Dear Simon, Thanks for your interest in our WebCL prototype in WebKit. Currently, it's integrated with WebKit r78407 and hasn't been checked with WebKit's coding style guidelines. It's tested on Mac with Nvidia GPU which supports OpenCL support. Updating the code to a newer WebKit and Porting the code to other platforms should be straightforward because the only platform-dependent part is OpenCL support. WebGL is not needed for WebCL itself, but it would be better for interoperability between WebCL and WebGL, so that's why we started this work on Mac first. Regards, Won -Original Message- From: Simon Fraser [mailto:simon.fra...@apple.com] Sent: Tuesday, July 05, 2011 8:12 AM To: Gyuyoung Kim Cc: webkit-dev@lists.webkit.org; Simon Gibbs; Won Jeon - SISA; jinwoo7.s...@samsung.com Subject: Re: [webkit-dev] WebCL Release On Jul 3, 2011, at 6:28 PM, Gyuyoung Kim wrote: Hello WebKit Developers, Samsung has just open sourced an implementation of WebCL for WebKit. This is a prototype of a proposed WebCL standard that aims to define JavaScript APIs for OpenCL. The code is located at http://code.google.com/p/webcl/ and some demo videos at http://www.youtube.com/user/SamsungSISA. We're interested in any feedback on the prototype and how it can be better integrated with WebKit. Perhaps you can summarize here how it works now, and what directions you see for closer integration with WebKit? Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
