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