---------- 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 中川祥:
> <mailto:madewokherd@gmail.com>>: