Want to add WebCL support into Blink on Windows.

[Zhang Peixuan]

All,
     I have sent email on April 7th, at that time I asked whether there is a plan to add WebCL/OpenCL support into Blink/Chromium, I know the biggest problem is to bypass the sandbox in Chromium, but I think Browsers need to support WebCL in the further. Is there any development plan now?
     Our team have tried to add WebCL support for Blink/Chromium on Windows, now it can' support WebCL with --no-sandbox, but we havn't implemented the WebCL interop with WebGL.
     I also have an idea to bypass sandbox, which is to define some IPC message, to call OpenCL API in renderer process, then run these API in GPU or browser process and return the results back. Now we have implemented this idea, and now we are doing some testing work to make sure it can work.
     Is the community interested in our work? If we want to contribute the code of these part, are you interested to accept it?

     Thanks a lot!

                                            Peixuan Zhang
                                                        2013/07/04

[Adam Barth]

I don't think that anything has changed since April.  As far as I am aware, we are not currently interested in supporting WebCL.

Adam

[Slavomir Kaslev]

In my opinion, implementing WebCL in the GPU process, exposing it through IPC with a client library that translates the WebCL API to the IPC is the way to go. This follows the way WebGL is implemented in Chrome (see src/gpu/command_buffer/service and src/gpu/command_buffer/client).

Extra care must be taken for security. This includes zero-initializing buffers and textures on creation, state and kernels validation, etc. For example, for WebGL we use ANGLE for GLSL validation and translation. Among other things, that also takes care of out-of-bounds indexing in arrays by translating |array[index]| to |array[clamp(index, 0, arraysize(array)-1)]|. Doing such validation and translation for the C99 flavor that OpenCL specifies will be harder (think pointer arithmetic).

Any WebCL implementation must resolve those issues to stand a chance to be taken seriously by the community.

Hope that helps.

Cheers,

-Slavi

On Wed, Jul 3, 2013 at 11:22 PM, Zhang Peixuan <zhangpe...@gmail.com> wrote:

--

Slavomir Kaslev | Software Engineer | ska...@google.com | 562 217 8497

[Kenneth Russell]

Agree with Slavi's points.

As I understand it, WebCL defines a subset of the OpenCL language that
can be verified, and translated to OpenCL in a way that guarantees
that no out-of-range memory accesses are performed by the kernel. That
language subset is the only one that can be safely exposed to Chrome's
renderer processes via the command buffer. Therefore a WebCL
implementation in Chrome will differ somewhat from the WebGL
implementation; WebGL is implemented via the command buffer on top of
the OpenGL ES 2.0 API, but WebCL would have to be implemented on top
of a modified version of the OpenCL API and kernel language.

-Ken

[Antonio Gomes]

Hi. Please find comments below.

Cheers,

--Antonio

On Mon, Jul 8, 2013 at 4:36 PM, Slavomir Kaslev <ska...@google.com> wrote:
>
>
> Extra care must be taken for security. This includes zero-initializing buffers and textures on creation, state and kernels validation, etc. For example, for WebGL we use ANGLE for GLSL validation and translation. Among other things, that also takes care of out-of-bounds indexing in arrays by translating |array[index]| to |array[clamp(index, 0, arraysize(array)-1)]|. Doing such validation and translation for the C99 flavor that OpenCL specifies will be harder (think pointer arithmetic).

Find below some considerations about the security aspects of WebCL in
an email originally sent to webkit-dev:

"Protecting against out-of-bounds memory access, and other
vulnerabilities, such as denial-of-service, has been a priority in the
design of WebCL since its inception. Khronos has defined a series of
security extensions designed to harden the OpenCL drivers on which
WebCL is based. Two OpenCL extensions proposed by the WebCL Working
Group (WG), have been ratified and are currently part of the OpenCL
extension specification.

- The "Memory Initialization" extension [1] enforces protection
against memory leakage.
- The "Context Termination" extension [2] provides protection against
denial-of-service;

In addition, the WebCL WG has started a project for a "WebCL Kernel
Validator" [3]. The validator will enforce out-of-bounds memory
protection, and will provide syntax validation for WebCL kernels. It
is not meant to be a reference implementation, but a sample
implementation of the enforcement of the language restrictions.

As GPU vendors start to implement the context termination and memory
initialization extensions in their respective OpenCL drivers, the
broader browser community has an opportunity to provide feedback to
this process. "

See the original email here:
http://mac-os-forge.2317878.n4.nabble.com/Some-thoughts-on-WebCL-td216051.html

In summary, the validator provides instrumentation to the kernel code
that includes out of bounds memory projection, by means of bound
checks, and memory initialization for global, private, and
local/shared memory. The goal is that future hardware is going to
support the “Memory initialization” extension and initialization of
these memories will no longer be needed.

Additionally, the validator is being developed as an open source
project, and initial measurements show that the possible performance
impact of the “validated” kernels are being quite low.

[1] http://www.khronos.org/registry/cl/specs/opencl-1.2-extensions.pdf
, see Section "9.15 Local and Private Memory Initialization" -
cl_khr_initialize_memory
[2] http://www.khronos.org/registry/cl/specs/opencl-1.2-extensions.pdf
, see Section "9.16 Terminating OpenCL contexts".
[3] https://github.com/KhronosGroup/webcl-validator

> Any WebCL implementation must resolve those issues to stand a chance to be taken seriously by the community.

Hope it helps to satisfy some of the security concerns raised.

--Antonio