OLD | NEW |
(Empty) | |
| 1 The Sandbox IPC system is separate from the 'main' IPC system. The sandbox IPC i
s a lower level system which deals with cases where we need to route requests fr
om the bottom of the call stack up into the browser. |
| 2 |
| 3 The motivating example is Skia, which uses fontconfig to load fonts. In a chroot
ed renderer we cannot access the user's fontcache, nor the font files themselves
. However, font loading happens when we have called through WebKit, through Skia
and into the SkFontHost. At this point, we cannot loop back around to use the m
ain IPC system. |
| 4 |
| 5 Thus we define a small IPC system which doesn't depend on anything but <tt>base<
/tt> and which can make synchronous requests to the browser process. |
| 6 |
| 7 The zygote (LinuxZygote) starts with a UNIX DGRAM socket installed in a well kno
wn file descriptor slot (currently 4). Requests can be written to this socket wh
ich are then processed on a special "sandbox IPC" process. Requests have a magic
<tt>int</tt> at the beginning giving the type of the request. |
| 8 |
| 9 All renderers share the same socket, so replies are delivered via a reply channe
l which is passed as part of the request. So the flow looks like: |
| 10 1. The renderer creates a UNIX DGRAM socketpair. |
| 11 1. The renderer writes a request to file descriptor 4 with an SCM\_RIGHTS cont
rol message containing one end of the fresh socket pair. |
| 12 1. The renderer blocks reading from the other end of the fresh socketpair. |
| 13 1. A special "sandbox IPC" process receives the request, processes it and writ
es the reply to the end of the socketpair contained in the request. |
| 14 1. The renderer wakes up and continues. |
| 15 |
| 16 The browser side of the processing occurs in <tt>chrome/browser/renderer_host/re
nder_sandbox_host_linux.cc</tt>. The renderer ends could occur anywhere, but the
browser side has to know about all the possible requests so that should be a go
od starting point. |
| 17 |
| 18 Here is a (possibly incomplete) list of endpoints in the renderer: |
| 19 |
| 20 ### fontconfig |
| 21 |
| 22 As mentioned above, the motivating example of this is dealing with fontconfig fr
om a chrooted renderer. We implement our own Skia FontHost, outside of the Skia
tree, in <tt>skia/ext/SkFontHost_fontconfig**</tt>.** |
| 23 |
| 24 There are two methods used. One for performing a match against the fontconfig da
ta and one to return a file descriptor to a font file resulting from one of thos
e matches. The only wrinkle is that fontconfig is a single-threaded library and
it's already used in the browser by GTK itself. |
| 25 |
| 26 Thus, we have a couple of options: |
| 27 1. Handle the requests on the UI thread in the browser. |
| 28 1. Handle the requests in a separate address space. |
| 29 |
| 30 The original implementation did the former (handle on UI thread). This turned ou
t to be a terrible idea, performance wise, so we now handle the requests on a de
dicated process. |
OLD | NEW |