OLD | NEW |
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. | 1 # Linux Sandbox IPC |
2 | 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. | 3 The Sandbox IPC system is separate from the 'main' IPC system. The sandbox IPC |
| 4 is a lower level system which deals with cases where we need to route requests |
| 5 from the bottom of the call stack up into the browser. |
4 | 6 |
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. | 7 The motivating example is Skia, which uses fontconfig to load fonts. In a |
| 8 chrooted renderer we cannot access the user's fontcache, nor the font files |
| 9 themselves. However, font loading happens when we have called through WebKit, |
| 10 through Skia and into the SkFontHost. At this point, we cannot loop back around |
| 11 to use the main IPC system. |
6 | 12 |
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. | 13 Thus we define a small IPC system which doesn't depend on anything but `base` |
| 14 and which can make synchronous requests to the browser process. |
8 | 15 |
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: | 16 The [zygote](linux_zygote.md) starts with a `UNIX DGRAM` socket installed in a |
10 1. The renderer creates a UNIX DGRAM socketpair. | 17 well known file descriptor slot (currently 4). Requests can be written to this |
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. | 18 socket which are then processed on a special "sandbox IPC" process. Requests |
12 1. The renderer blocks reading from the other end of the fresh socketpair. | 19 have a magic `int` at the beginning giving the type of the request. |
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 | 20 |
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. | 21 All renderers share the same socket, so replies are delivered via a reply |
| 22 channel which is passed as part of the request. So the flow looks like: |
| 23 |
| 24 1. The renderer creates a `UNIX DGRAM` socketpair. |
| 25 1. The renderer writes a request to file descriptor 4 with an `SCM_RIGHTS` |
| 26 control message containing one end of the fresh socket pair. |
| 27 1. The renderer blocks reading from the other end of the fresh socketpair. |
| 28 1. A special "sandbox IPC" process receives the request, processes it and |
| 29 writes the reply to the end of the socketpair contained in the request. |
| 30 1. The renderer wakes up and continues. |
| 31 |
| 32 The browser side of the processing occurs in |
| 33 `chrome/browser/renderer_host/render_sandbox_host_linux.cc`. The renderer ends |
| 34 could occur anywhere, but the browser side has to know about all the possible |
| 35 requests so that should be a good starting point. |
17 | 36 |
18 Here is a (possibly incomplete) list of endpoints in the renderer: | 37 Here is a (possibly incomplete) list of endpoints in the renderer: |
19 | 38 |
20 ### fontconfig | 39 ### fontconfig |
21 | 40 |
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>.** | 41 As mentioned above, the motivating example of this is dealing with fontconfig |
| 42 from a chrooted renderer. We implement our own Skia FontHost, outside of the |
| 43 Skia tree, in `skia/ext/SkFontHost_fontconfig**`. |
23 | 44 |
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. | 45 There are two methods used. One for performing a match against the fontconfig |
| 46 data and one to return a file descriptor to a font file resulting from one of |
| 47 those matches. The only wrinkle is that fontconfig is a single-threaded library |
| 48 and it's already used in the browser by GTK itself. |
25 | 49 |
26 Thus, we have a couple of options: | 50 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 | 51 |
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. | 52 1. Handle the requests on the UI thread in the browser. |
| 53 1. Handle the requests in a separate address space. |
| 54 |
| 55 The original implementation did the former (handle on UI thread). This turned |
| 56 out to be a terrible idea, performance wise, so we now handle the requests on a |
| 57 dedicated process. |
OLD | NEW |