Now,we don't run wine in Chrome OS. Google also think they can run windows executable files. My idea is about how to use wine in the OS. Google Chrome has two types of extensions:one is the extension,that support only web technology.the other is PPAPI,Google Native Client. Here's the overview↓ https://developers.google.com/native-client/dev/overview For example,Flash Player uses PPAPI. C/C++ programs can be transformed and run in its sandbox. then we can run wine in Chrome OS. I think if wine supports Chrome OS,Google helps us.
I don't think it's possible for existing Windows code to run in Native Client. As I understand it, NaCl verifies all x86 code to make sure it's safe before executing it, and Wine needs to load x86 code compiled for Windows directly, which will not be using the safe subset of x86 that NaCl requires.
One would need a proper virtual machine to make that work, something like qemu perhaps.
However, the pipelight project may be interested in support for PPAPI.
So,you think wine behaves as if runnig vulnerable code itself? Like the oldest Java did? Then as the latest Java does,compile windows code to Linux .so files, and NaCl scans it.
2014-02-20 1:06 GMT+09:00 Vincent Povirk madewokherd@gmail.com:
I don't think it's possible for existing Windows code to run in Native Client. As I understand it, NaCl verifies all x86 code to make sure it's safe before executing it, and Wine needs to load x86 code compiled for Windows directly, which will not be using the safe subset of x86 that NaCl requires.
One would need a proper virtual machine to make that work, something like qemu perhaps.
However, the pipelight project may be interested in support for PPAPI.
Hi,
you first need to distinguish between the PPAPI and the NaCL modules. Both use the same API interface but the main difference is that PPAPI plugins (called as PPAPI (Out-of-Process) in Chrome) can be compiled with an ordinary gcc while the NaCL modules are compiled with a compiler distributed in the Google NDK.
In difference to the older NPAPI which only provides helper functions to communicate with the browser, the PPAPI is meant as a replacement for system specific APIs. This means that if you want to use a socket, draw something or use a sound device, you are supposed to use the interfaces provided by the browser.
If you want to make Wine compatible with such interfaces you would need to rewrite everything which interacts with the POSIX API to use a browser interface instead. This is a lot of work and you won't be able to get everything working as the interfaces have access restrictions, you are for example not allowed to make arbitrary HTTP requests, they must follow the "Cross-Origin Resource Sharing" rules.
When you develop a NaCL module, you simply won't get access to the normal POSIX API and the code is scanned for forbidden Opcodes to enforce these restrictions. One idea behind NaCL modules is that they should be portable and it is therefore not intended to link against system specific libraries. From my point of view it is nearly impossible to convert Wine into a NaCL module
The PPAPI modules are only loaded into a seccomp sandbox, so that your process would be killed if you try to use something else than the browser interface. Since this is actually a bit cruel for porting plugins to the PPAPI, Google decided to hook the normal stdlib so that you will get an error code when you try to execute for example fork() instead of killing the plugin. There is only one way to get around these restrictions by disabling sandboxing in chrome by starting the browser with "--disable-sandbox", so that you will get full access to the whole POSIX API again. Anyway, while this would make it possible to convert Wine into a PPAPI module this is not really a good solution from a security point of view. Moreover PPAPI plugins are not officially supported by Chrome, you can not simply register them but instead need some obscure command line parameters.
We actually solve this problem in Pipelight by executing Wine as a separate process which has full access to the system specific APIs. We therefore only need a way to communicate with the outer part which is currently done via stdin/stdout. While this is not compatible with the Sandbox we are going to replace the pipes with sockets in future so that we should be able to use the Sandbox again. This might even work with NaCL modules.
To sum it up: The provided interfaces are not powerful enough to run Wine as a sandboxed plugin. You may disable the sandbox and port some parts of Wine to actually use for example the audio interface or to draw a desktop into a plugin area, but I doubt that someone is actually going to use Chrome without a sandbox. For ChromeOS all this gets even more difficult, because I doubt that you'll even be able to execute Chrome without a sandbox.
Michael
Am 20.02.2014 11:10, schrieb 中川祥:
So,you think wine behaves as if runnig vulnerable code itself? Like the oldest Java did? Then as the latest Java does,compile windows code to Linux .so files, and NaCl scans it.
2014-02-20 1:06 GMT+09:00 Vincent Povirk <madewokherd@gmail.com mailto:madewokherd@gmail.com>:
I don't think it's possible for existing Windows code to run in Native Client. As I understand it, NaCl verifies all x86 code to make sure it's safe before executing it, and Wine needs to load x86 code compiled for Windows directly, which will not be using the safe subset of x86 that NaCl requires. One would need a proper virtual machine to make that work, something like qemu perhaps. However, the pipelight project may be interested in support for PPAPI.
---------- Forwarded message ---------- From: Michael Müller michael@fds-team.de Date: 2014-02-21 2:29 GMT+09:00 Subject: Re: [idea]wine support for Chrome OS To: 中川祥 matyapiro31@gmail.com, madewokherd@gmail.com, wine-devel < wine-devel@winehq.org>
Hi,
you first need to distinguish between the PPAPI and the NaCL modules. Both use the same API interface but the main difference is that PPAPI plugins (called as PPAPI (Out-of-Process) in Chrome) can be compiled with an ordinary gcc while the NaCL modules are compiled with a compiler distributed in the Google NDK.
In difference to the older NPAPI which only provides helper functions to communicate with the browser, the PPAPI is meant as a replacement for system specific APIs. This means that if you want to use a socket, draw something or use a sound device, you are supposed to use the interfaces provided by the browser.
If you want to make Wine compatible with such interfaces you would need to rewrite everything which interacts with the POSIX API to use a browser interface instead. This is a lot of work and you won't be able to get everything working as the interfaces have access restrictions, you are for example not allowed to make arbitrary HTTP requests, they must follow the "Cross-Origin Resource Sharing" rules.
When you develop a NaCL module, you simply won't get access to the normal POSIX API and the code is scanned for forbidden Opcodes to enforce these restrictions. One idea behind NaCL modules is that they should be portable and it is therefore not intended to link against system specific libraries. From my point of view it is nearly impossible to convert Wine into a NaCL module
The PPAPI modules are only loaded into a seccomp sandbox, so that your process would be killed if you try to use something else than the browser interface. Since this is actually a bit cruel for porting plugins to the PPAPI, Google decided to hook the normal stdlib so that you will get an error code when you try to execute for example fork() instead of killing the plugin. There is only one way to get around these restrictions by disabling sandboxing in chrome by starting the browser with "--disable-sandbox", so that you will get full access to the whole POSIX API again. Anyway, while this would make it possible to convert Wine into a PPAPI module this is not really a good solution from a security point of view. Moreover PPAPI plugins are not officially supported by Chrome, you can not simply register them but instead need some obscure command line parameters.
We actually solve this problem in Pipelight by executing Wine as a separate process which has full access to the system specific APIs. We therefore only need a way to communicate with the outer part which is currently done via stdin/stdout. While this is not compatible with the Sandbox we are going to replace the pipes with sockets in future so that we should be able to use the Sandbox again. This might even work with NaCL modules.
To sum it up: The provided interfaces are not powerful enough to run Wine as a sandboxed plugin. You may disable the sandbox and port some parts of Wine to actually use for example the audio interface or to draw a desktop into a plugin area, but I doubt that someone is actually going to use Chrome without a sandbox. For ChromeOS all this gets even more difficult, because I doubt that you'll even be able to execute Chrome without a sandbox.
Michael
Am 20.02.2014 11:10, schrieb 中川祥:
So,you think wine behaves as if runnig vulnerable code itself? Like the oldest Java did? Then as the latest Java does,compile windows code to Linux .so files, and NaCl scans it.
2014-02-20 1:06 GMT+09:00 Vincent Povirk <madewokherd@gmail.com mailto:madewokherd@gmail.com>:
I don't think it's possible for existing Windows code to run in Native Client. As I understand it, NaCl verifies all x86 code to make sure it's safe before executing it, and Wine needs to load x86 code compiled for Windows directly, which will not be using the safe subset of x86 that NaCl requires. One would need a proper virtual machine to make that work, something like qemu perhaps. However, the pipelight project may be interested in support for PPAPI.
---------- Forwarded message ---------- From: Michael Müller michael@fds-team.de Date: 2014-02-21 2:29 GMT+09:00 Subject: Re: [idea]wine support for Chrome OS To: 中川祥 matyapiro31@gmail.com, madewokherd@gmail.com, wine-devel < wine-devel@winehq.org>
Hi,
you first need to distinguish between the PPAPI and the NaCL modules. Both use the same API interface but the main difference is that PPAPI plugins (called as PPAPI (Out-of-Process) in Chrome) can be compiled with an ordinary gcc while the NaCL modules are compiled with a compiler distributed in the Google NDK.
In difference to the older NPAPI which only provides helper functions to communicate with the browser, the PPAPI is meant as a replacement for system specific APIs. This means that if you want to use a socket, draw something or use a sound device, you are supposed to use the interfaces provided by the browser.
If you want to make Wine compatible with such interfaces you would need to rewrite everything which interacts with the POSIX API to use a browser interface instead. This is a lot of work and you won't be able to get everything working as the interfaces have access restrictions, you are for example not allowed to make arbitrary HTTP requests, they must follow the "Cross-Origin Resource Sharing" rules.
When you develop a NaCL module, you simply won't get access to the normal POSIX API and the code is scanned for forbidden Opcodes to enforce these restrictions. One idea behind NaCL modules is that they should be portable and it is therefore not intended to link against system specific libraries. From my point of view it is nearly impossible to convert Wine into a NaCL module
The PPAPI modules are only loaded into a seccomp sandbox, so that your process would be killed if you try to use something else than the browser interface. Since this is actually a bit cruel for porting plugins to the PPAPI, Google decided to hook the normal stdlib so that you will get an error code when you try to execute for example fork() instead of killing the plugin. There is only one way to get around these restrictions by disabling sandboxing in chrome by starting the browser with "--disable-sandbox", so that you will get full access to the whole POSIX API again. Anyway, while this would make it possible to convert Wine into a PPAPI module this is not really a good solution from a security point of view. Moreover PPAPI plugins are not officially supported by Chrome, you can not simply register them but instead need some obscure command line parameters.
We actually solve this problem in Pipelight by executing Wine as a separate process which has full access to the system specific APIs. We therefore only need a way to communicate with the outer part which is currently done via stdin/stdout. While this is not compatible with the Sandbox we are going to replace the pipes with sockets in future so that we should be able to use the Sandbox again. This might even work with NaCL modules.
To sum it up: The provided interfaces are not powerful enough to run Wine as a sandboxed plugin. You may disable the sandbox and port some parts of Wine to actually use for example the audio interface or to draw a desktop into a plugin area, but I doubt that someone is actually going to use Chrome without a sandbox. For ChromeOS all this gets even more difficult, because I doubt that you'll even be able to execute Chrome without a sandbox.
Michael
Am 20.02.2014 11:10, schrieb 中川祥:
So,you think wine behaves as if runnig vulnerable code itself? Like the oldest Java did? Then as the latest Java does,compile windows code to Linux .so files, and NaCl scans it.
2014-02-20 1:06 GMT+09:00 Vincent Povirk <madewokherd@gmail.com mailto:madewokherd@gmail.com>:
I don't think it's possible for existing Windows code to run in Native Client. As I understand it, NaCl verifies all x86 code to make sure it's safe before executing it, and Wine needs to load x86 code compiled for Windows directly, which will not be using the safe subset of x86 that NaCl requires. One would need a proper virtual machine to make that work, something like qemu perhaps. However, the pipelight project may be interested in support for PPAPI.
-
Michael Müller -
Vincent Povirk -
中川祥