OpenCL support within NaCl

[Fernando Carvalho]

Dear Native client community,

I'm very excited about the possibilities that Native Client is giving to Web developers.

So I would like to ask if there are chances to add OpenCL support to NaCl.

I know that even in the browser, there is no stable WebCL implementation, and this capability may be something that should first be supported, before OpenCL could be imported to NaCl.

Thus the question here is also about in what stage GPU general purpose processing is in the browser? 

Many thanks,

--
Fernando

[Andrey Khalyavin]

The work on OpenCL support haven't even started and there are no plans to start this work. Sorry.

-- Andrey Khalyavin

[Faldegast]

Doesn't JavaScript functionality require support in PPAPI? How do you plan to support WebCL without support in Pepper?

[Victor Khimenko]

On Fri, Aug 2, 2013 at 5:21 PM, Faldegast <fald...@gmail.com> wrote:

Doesn't JavaScript functionality require support in PPAPI?

JavaScript has nothing to with PPAPI, it's directly embedded in renderer. Flash needs PPAPI, though - but even in this case interface can be exposed to Flash and not exposed to NaCl's untrusted code.

But for any feature to be available via PPAPI and/or via JavaScript it must be implemented in browser core first. Then and only then JavaScript/PPAPI bindings can be provided - and JavaScript usually receives features before PPAPI.

 

How do you plan to support WebCL without support in Pepper?

Who said anything about supporting WebCL any time soon? There are some WebCL experiments floating around (not backed by Google AFAIK), but they were experiments two years ago and they still are just an experiments. When and if they'll become something more we can start talking about PPAPI/NaCl access.

 

Den fredagen den 2:e augusti 2013 kl. 00:06:22 UTC+2 skrev Andrey Khalyavin:

The work on OpenCL support haven't even started and there are no plans to start this work. Sorry.

-- Andrey Khalyavin

On Thursday, August 1, 2013 1:42:29 PM UTC-7, Fernando Carvalho wrote:

Dear Native client community,

I'm very excited about the possibilities that Native Client is giving to Web developers.

So I would like to ask if there are chances to add OpenCL support to NaCl.

I know that even in the browser, there is no stable WebCL implementation, and this capability may be something that should first be supported, before OpenCL could be imported to NaCl.

Thus the question here is also about in what stage GPU general purpose processing is in the browser? 

Many thanks,

--
Fernando

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to native-client-di...@googlegroups.com.
To post to this group, send email to native-cli...@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Faldegast]

Oh, I assumed that Javascript and Flash was sandboxed in order to reach maximum security. How can a PPAPI plugin become trusted enough to have access to the functionality Flash have?

Could I write a trusted plugin that are still able to sandbox part of itself as untrusted code?

Den fredagen den 2:e augusti 2013 kl. 15:37:52 UTC+2 skrev khim:

On Fri, Aug 2, 2013 at 5:21 PM, Faldegast <fald...@gmail.com> wrote:

Doesn't JavaScript functionality require support in PPAPI?

JavaScript has nothing to with PPAPI, it's directly embedded in renderer. Flash needs PPAPI, though - but even in this case interface can be exposed to Flash and not exposed to NaCl's untrusted code.

But for any feature to be available via PPAPI and/or via JavaScript it must be implemented in browser core first. Then and only then JavaScript/PPAPI bindings can be provided - and JavaScript usually receives features before PPAPI.

 

How do you plan to support WebCL without support in Pepper?

Who said anything about supporting WebCL any time soon? There are some WebCL experiments floating around (not backed by Google AFAIK), but they were experiments two years ago and they still are just an experiments. When and if they'll become something more we can start talking about PPAPI/NaCl access.

 

Den fredagen den 2:e augusti 2013 kl. 00:06:22 UTC+2 skrev Andrey Khalyavin:

The work on OpenCL support haven't even started and there are no plans to start this work. Sorry.

-- Andrey Khalyavin

On Thursday, August 1, 2013 1:42:29 PM UTC-7, Fernando Carvalho wrote:

Dear Native client community,

I'm very excited about the possibilities that Native Client is giving to Web developers.

So I would like to ask if there are chances to add OpenCL support to NaCl.

I know that even in the browser, there is no stable WebCL implementation, and this capability may be something that should first be supported, before OpenCL could be imported to NaCl.

Thus the question here is also about in what stage GPU general purpose processing is in the browser? 

Many thanks,

--
Fernando

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to native-client-discuss+unsub...@googlegroups.com.

[Victor Khimenko]

On Wed, Aug 7, 2013 at 7:53 PM, Faldegast <fald...@gmail.com> wrote:

Oh, I assumed that Javascript and Flash was sandboxed in order to reach maximum security.

They only have outer sandbox. NaCl process has two. Understandable, really: in both cases we have JITs which are not supposed to produce vulnerable code while NaCl process executes user-provided CPU code directly. There were some talks about using NaCl to make renderer and/or Flash more secure, but this will be huge project and even if it'll eventually happen it'll not happen any time soon.

 

How can a PPAPI plugin become trusted enough to have access to the functionality Flash have?

You must convince Chromium (or Chrome if we are talking about plugins like Flash or PDF) developers to ship your plugin as part of default installation. And even then it's not guaranteed.

 

Could I write a trusted plugin that are still able to sandbox part of itself as untrusted code?

You probably can, but this is not something worth doing, really: you can not distribute said plugin. It must be manually installed and future versions of Chrome can break it without warnings. Thus, practically speaking, trusted plugin is useful step for porting, but not for much more:

http://mainroach.blogspot.ru/2012/05/porting-to-native-client-with-visual.html

 

To unsubscribe from this group and stop receiving emails from it, send an email to native-client-di...@googlegroups.com.

[Faldegast]

On Wednesday, August 7, 2013 8:25:21 PM UTC+2, khim wrote:

On Wed, Aug 7, 2013 at 7:53 PM, Faldegast <fald...@gmail.com> wrote:

Oh, I assumed that Javascript and Flash was sandboxed in order to reach maximum security.

They only have outer sandbox. NaCl process has two. Understandable, really: in both cases we have JITs which are not supposed to produce vulnerable code while NaCl process executes user-provided CPU code directly. There were some talks about using NaCl to make renderer and/or Flash more secure, but this will be huge project and even if it'll eventually happen it'll not happen any time soon.

As I come from a .NET/Java perspective on how to handle these things I assumed that there was one sandbox and that the JavaScript compiler just generated NaCl code like the .NET and Java solutions generate CIL/bytecode. This to pose a problem for my project because I was planning to rely on NaCl sandboxing entirely and from your information it seams like that's not going to be possible.

 

How can a PPAPI plugin become trusted enough to have access to the functionality Flash have?

You must convince Chromium (or Chrome if we are talking about plugins like Flash or PDF) developers to ship your plugin as part of default installation. And even then it's not guaranteed.

 

We are talking about LightSpark and icedtea-web and similar on Linux which means Chromium package developers have to be convinced. For my specific needs I can always build my own packages on the suse build servers. So what I'm asking is how do I do this if I am the Chromium developer? Frankly the current plans to retire NPAPI without having a easy way to make equivalent PPAPI plugins will be a problem, as both LightSpark and icedtea-web are currently NPAPI.

 

Could I write a trusted plugin that are still able to sandbox part of itself as untrusted code?

You probably can, but this is not something worth doing, really: you can not distribute said plugin. It must be manually installed and future versions of Chrome can break it without warnings. Thus, practically speaking, trusted plugin is useful step for porting, but not for much more:

http://mainroach.blogspot.ru/2012/05/porting-to-native-client-with-visual.html

This is no different than what plugins usually have to deal with. Why do you think that all new browser versions are Q&A-tested by both Fedora and Ubuntu for weeks before being pushed into the repositories? Frankly I am beginning to think that it might have been a better idea to base NaCl on existing tech like Mono or OpenJDK which has sandboxing models that are quite mature and can do everything I have asked about. 

If I want to extend Java with OpenCL I would make an "Installable extension" which means I would put a JAR in $jre/lib/ext and then Java Applets would be able to access it. As it would be a system library (by being in lib/ext) it would be able to use OpenCL or whatever low-level API:s i desire.

 

Den fredagen den 2:e augusti 2013 kl. 15:37:52 UTC+2 skrev khim:

On Fri, Aug 2, 2013 at 5:21 PM, Faldegast <fald...@gmail.com> wrote:

Doesn't JavaScript functionality require support in PPAPI?

JavaScript has nothing to with PPAPI, it's directly embedded in renderer. Flash needs PPAPI, though - but even in this case interface can be exposed to Flash and not exposed to NaCl's untrusted code.

But for any feature to be available via PPAPI and/or via JavaScript it must be implemented in browser core first. Then and only then JavaScript/PPAPI bindings can be provided - and JavaScript usually receives features before PPAPI.

 

How do you plan to support WebCL without support in Pepper?

Who said anything about supporting WebCL any time soon? There are some WebCL experiments floating around (not backed by Google AFAIK), but they were experiments two years ago and they still are just an experiments. When and if they'll become something more we can start talking about PPAPI/NaCl access.

 

Den fredagen den 2:e augusti 2013 kl. 00:06:22 UTC+2 skrev Andrey Khalyavin:

The work on OpenCL support haven't even started and there are no plans to start this work. Sorry.

-- Andrey Khalyavin

On Thursday, August 1, 2013 1:42:29 PM UTC-7, Fernando Carvalho wrote:

Dear Native client community,

I'm very excited about the possibilities that Native Client is giving to Web developers.

So I would like to ask if there are chances to add OpenCL support to NaCl.

I know that even in the browser, there is no stable WebCL implementation, and this capability may be something that should first be supported, before OpenCL could be imported to NaCl.

Thus the question here is also about in what stage GPU general purpose processing is in the browser? 

Many thanks,

--
Fernando

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to native-client-discuss+unsubscri...@googlegroups.com.

To post to this group, send email to native-cli...@googlegroups.com.

Visit this group at http://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Victor Khimenko]

On Sat, Sep 28, 2013 at 12:21 PM, Faldegast <fald...@gmail.com> wrote:

On Wednesday, August 7, 2013 8:25:21 PM UTC+2, khim wrote:

On Wed, Aug 7, 2013 at 7:53 PM, Faldegast <fald...@gmail.com> wrote:

Oh, I assumed that Javascript and Flash was sandboxed in order to reach maximum security.

They only have outer sandbox. NaCl process has two. Understandable, really: in both cases we have JITs which are not supposed to produce vulnerable code while NaCl process executes user-provided CPU code directly. There were some talks about using NaCl to make renderer and/or Flash more secure, but this will be huge project and even if it'll eventually happen it'll not happen any time soon.

As I come from a .NET/Java perspective on how to handle these things I assumed that there was one sandbox and that the JavaScript compiler just generated NaCl code like the .NET and Java solutions generate CIL/bytecode.

There are exist port of V8 to NaCl, you can try to use it if you wish.

 

This to pose a problem for my project because I was planning to rely on NaCl sandboxing entirely and from your information it seams like that's not going to be possible.

It's possible (as I've noted there are discussions about doing exactly that), just hard. It'll be large work if you'll decide to go that route.

 

How can a PPAPI plugin become trusted enough to have access to the functionality Flash have?

You must convince Chromium (or Chrome if we are talking about plugins like Flash or PDF) developers to ship your plugin as part of default installation. And even then it's not guaranteed.

 

We are talking about LightSpark and icedtea-web and similar on Linux which means Chromium package developers have to be convinced.

Probably. Then you can do the same thing PPAPI Flash are doing. You can either use NaCl and run it in separate process (but this will be challenge because of synchronization issue), or you can try to do in-process PPAPI plugin (although I'm not sure how well-documented this capability is).

 

For my specific needs I can always build my own packages on the suse build servers. So what I'm asking is how do I do this if I am the Chromium developer?

There are documentation for PPAPI developers, etc:

https://sites.google.com/a/chromium.org/dev/developers/design-documents/pepper-plugin-implementation

 

Frankly the current plans to retire NPAPI without having a easy way to make equivalent PPAPI plugins will be a problem, as both LightSpark and icedtea-web are currently NPAPI.

I understand your pain, but that's the whole point: PPAPI was developed because it's hard to implement proper sandboxing and keep the basic NPAPI model intact.

 

Could I write a trusted plugin that are still able to sandbox part of itself as untrusted code?

You probably can, but this is not something worth doing, really: you can not distribute said plugin. It must be manually installed and future versions of Chrome can break it without warnings. Thus, practically speaking, trusted plugin is useful step for porting, but not for much more:

http://mainroach.blogspot.ru/2012/05/porting-to-native-client-with-visual.html

This is no different than what plugins usually have to deal with. Why do you think that all new browser versions are Q&A-tested by both Fedora and Ubuntu for weeks before being pushed into the repositories? Frankly I am beginning to think that it might have been a better idea to base NaCl on existing tech like Mono or OpenJDK which has sandboxing models that are quite mature and can do everything I have asked about.

Well lack one critical capability: the ability to use them in browser.

If I want to extend Java with OpenCL I would make an "Installable extension" which means I would put a JAR in $jre/lib/ext and then Java Applets would be able to access it. As it would be a system library (by being in lib/ext) it would be able to use OpenCL or whatever low-level API:s i desire.

And this nicely explains the reasons behind NPAPI retiring. System libraries and web are not things that should be mixed. They were nice as stop-gap solution, but now it's time to retire them.

 

Den fredagen den 2:e augusti 2013 kl. 15:37:52 UTC+2 skrev khim:

On Fri, Aug 2, 2013 at 5:21 PM, Faldegast <fald...@gmail.com> wrote:

Doesn't JavaScript functionality require support in PPAPI?

JavaScript has nothing to with PPAPI, it's directly embedded in renderer. Flash needs PPAPI, though - but even in this case interface can be exposed to Flash and not exposed to NaCl's untrusted code.

But for any feature to be available via PPAPI and/or via JavaScript it must be implemented in browser core first. Then and only then JavaScript/PPAPI bindings can be provided - and JavaScript usually receives features before PPAPI.

 

How do you plan to support WebCL without support in Pepper?

Who said anything about supporting WebCL any time soon? There are some WebCL experiments floating around (not backed by Google AFAIK), but they were experiments two years ago and they still are just an experiments. When and if they'll become something more we can start talking about PPAPI/NaCl access.

 

j

To unsubscribe from this group and stop receiving emails from it, send an email to native-client-di...@googlegroups.com.

[Faldegast]

On Saturday, September 28, 2013 at 5:16:07 PM UTC+2, khim wrote:

On Sat, Sep 28, 2013 at 12:21 PM, Faldegast <fald...@gmail.com> wrote:

On Wednesday, August 7, 2013 8:25:21 PM UTC+2, khim wrote:

On Wed, Aug 7, 2013 at 7:53 PM, Faldegast <fald...@gmail.com> wrote:

Oh, I assumed that Javascript and Flash was sandboxed in order to reach maximum security.

They only have outer sandbox. NaCl process has two. Understandable, really: in both cases we have JITs which are not supposed to produce vulnerable code while NaCl process executes user-provided CPU code directly. There were some talks about using NaCl to make renderer and/or Flash more secure, but this will be huge project and even if it'll eventually happen it'll not happen any time soon.

As I come from a .NET/Java perspective on how to handle these things I assumed that there was one sandbox and that the JavaScript compiler just generated NaCl code like the .NET and Java solutions generate CIL/bytecode.

There are exist port of V8 to NaCl, you can try to use it if you wish.

That's bot the point. A JavaScript compiler (like Nashorn) will always outperform V8. Secondly by not sandboxing JavaScript it becomes less secure than plugins that run inside the NaCl sandbox. So basically speed and security both become compromised. Why have less security for the JavaScript engine that has been proven to be the highest security risk in browsers than you require of third party technologies. The same goes for Flash.

 

This to pose a problem for my project because I was planning to rely on NaCl sandboxing entirely and from your information it seams like that's not going to be possible.

It's possible (as I've noted there are discussions about doing exactly that), just hard. It'll be large work if you'll decide to go that route.

Well it's not possible if NaCl doesn't provide all capabilities I need. 

How can a PPAPI plugin become trusted enough to have access to the functionality Flash have?

You must convince Chromium (or Chrome if we are talking about plugins like Flash or PDF) developers to ship your plugin as part of default installation. And even then it's not guaranteed.

 

We are talking about LightSpark and icedtea-web and similar on Linux which means Chromium package developers have to be convinced.

Probably. Then you can do the same thing PPAPI Flash are doing. You can either use NaCl and run it in separate process (but this will be challenge because of synchronization issue), or you can try to do in-process PPAPI plugin (although I'm not sure how well-documented this capability is).

As far as I have found, It's not well documented at all...

 

For my specific needs I can always build my own packages on the suse build servers. So what I'm asking is how do I do this if I am the Chromium developer?

There are documentation for PPAPI developers, etc:

https://sites.google.com/a/chromium.org/dev/developers/design-documents/pepper-plugin-implementation

Which unfortunately don't cover all that I need.

 

Frankly the current plans to retire NPAPI without having a easy way to make equivalent PPAPI plugins will be a problem, as both LightSpark and icedtea-web are currently NPAPI.

I understand your pain, but that's the whole point: PPAPI was developed because it's hard to implement proper sandboxing and keep the basic NPAPI model intact.

How is that hard?  Java Applets for example have had proper sandboxing for ages and it have worked well. Unfortunately that technology also is as limited as PPAPI + NaCl, if not more limited. I don't see how NPAPI made it hard to do that. Except of course that NPAPI being a spaghetti standard full with cross-browser incompatibilities makes it hard to do anything, but that's a whole different issue.

Could I write a trusted plugin that are still able to sandbox part of itself as untrusted code?

You probably can, but this is not something worth doing, really: you can not distribute said plugin. It must be manually installed and future versions of Chrome can break it without warnings. Thus, practically speaking, trusted plugin is useful step for porting, but not for much more:

http://mainroach.blogspot.ru/2012/05/porting-to-native-client-with-visual.html

This is no different than what plugins usually have to deal with. Why do you think that all new browser versions are Q&A-tested by both Fedora and Ubuntu for weeks before being pushed into the repositories? Frankly I am beginning to think that it might have been a better idea to base NaCl on existing tech like Mono or OpenJDK which has sandboxing models that are quite mature and can do everything I have asked about.

"Well lack one critical capability: the ability to use them in browser."

So does LLVM which is the technology that PPAPI is based on, but that didn't seam to bother you. Mono runs well in browsers as used by the Unity project. Java also runs in browsers in various flavors, including Java Applets. The only advantage with PPAPI over Java Applets are OpenGL and sound support. However as you know SUN abandoned the idea of using "proper sandboxing" and cave in to the requirements of having direct access to native code by introducing "Web Start"/JNLP which have been a mayor security problems ever sense.

If I want to extend Java with OpenCL I would make an "Installable extension" which means I would put a JAR in $jre/lib/ext and then Java Applets would be able to access it. As it would be a system library (by being in lib/ext) it would be able to use OpenCL or whatever low-level API:s i desire.

"And this nicely explains the reasons behind NPAPI retiring. System libraries and web are not things that should be mixed. They were nice as stop-gap solution, but now it's time to retire them."

And I agree on everything there except for the last part. "now it's time to retire them". It's not. There are a certain latency in this reply, but two years later there are no viable alternative to NPAPI plugins. While the undocumented out-of-process model of the PPAPI Flash may be an alternative, it still does exactly what you say is the problem with NPAPI - directly accessing system Libraries.

It can only be time to retire direct access to system libraries if there is full access to indirect access to system libraries. Today there are for ways you can get full access to them. Java Extentions, JNLP, NPAPI and PPAPI with separate process (correct me if I am wrong). Only one of these is intended to provide indirect access to system libraries. And as far as I know there are only one Java Extension that can be used this way and that's Java Cryptographic Architecture (JCA) which is also an excellent example of how third party native-web integration should be done.

For every example of web application that use NPAPI, JNLP and PPAPI with direct access to system libraries, I can elaborate on how writing a Java Extension and a Java Applet would have been better in all ways. More secure, more stable and easier to code.

However with Chrome currently Java Applets with Java Extensions ain't available, because that in turn need either NPAPI or out-of-proc PPAPI which ain't documented. And NaCl while being very similar to Java Applets do not have an extension mechanism, at least not one that is as easy to use as Java Extensions.

So for writing web applications direct access to system libraries from plugins like Flash, Java Applets, Unity engine, Quake Live etc cannot be retired.

I would argue that allowing extensions to the PPAPI like how Java allows dropping libraries in $jre/lib/ext may be a solution where third party developers can create abstraction layers for system API:s. That should be enough. Java had its this capability all along and the only project ever to use it was the Java Cryptographic Architecture (JCA). When people wanted 3D graphics they used system libraries directly, however that's probably because they cold. If they only way to get native capabilities in Chrome is to extend PPAPI that's what developers will do. And if we can do that, I am all for dropping NPAPI because at that point it would be redundant.

Meanwhile I think that implementing an out of process plugin like Flash would be the way to go. Now how do I do that? Can I get a window handle where I can draw graphics or do I have to somehow do that trough the sandbox?