| andybons | ad92aa3 | 2015-08-31 02:27:44 | [diff] [blame] | 1 | # Linux Sandbox IPC |
| andybons | 3322f76 | 2015-08-24 21:37:09 | [diff] [blame] | 2 | |
| andybons | ad92aa3 | 2015-08-31 02:27:44 | [diff] [blame] | 3 | TheSandbox IPC systemis separatefrom the'main' IPC system.The sandbox IPC |
| 4 | is a lower level system which dealswith caseswhere we need to route requests |
| 5 | from the bottom of the call stack upinto the browser. |
| andybons | 3322f76 | 2015-08-24 21:37:09 | [diff] [blame] | 6 | |
| Dominik Röttsches | ac24004 | 2018-07-06 09:52:40 | [diff] [blame] | 7 | The motivating example used to beSkia, which uses fontconfig to load |
| 8 | fonts.Howvever, the OOP IPCforFontConfig was moved tousingFontServiceand |
| 9 | the`components/services/font/public/cpp/font_loader.h`interface. |
| 10 | |
| 11 | These days, only theout-of-process localtime implementationas wellas |
| 12 | an OOP callfor making a shared memory segment areusing theSandbox IPC |
| 13 | file-descriptor based system.See`sandbox/linux/services/libc_interceptor.cc`. |
| andybons | 3322f76 | 2015-08-24 21:37:09 | [diff] [blame] | 14 | |
| andybons | ad92aa3 | 2015-08-31 02:27:44 | [diff] [blame] | 15 | Thus we define a small IPC system which doesn't depend on anything but `base` |
| 16 | and which can make synchronous requests to the browser process. |
| andybons | 3322f76 | 2015-08-24 21:37:09 | [diff] [blame] | 17 | |
| Tom Anderson | 93e49e49 | 2019-12-23 19:55:37 | [diff] [blame] | 18 | The [zygote](zygote.md) starts with a `UNIX DGRAM` socket installed in a |
| andybons | ad92aa3 | 2015-08-31 02:27:44 | [diff] [blame] | 19 | well known file descriptor slot (currently 4). Requests can be written to this |
| 20 | socket which are then processed on a special "sandbox IPC" process. Requests |
| 21 | have a magic `int` at the beginning giving the type of the request. |
| andybons | 3322f76 | 2015-08-24 21:37:09 | [diff] [blame] | 22 | |
| andybons | ad92aa3 | 2015-08-31 02:27:44 | [diff] [blame] | 23 | All renderers share the same socket, so replies are delivered via a reply |
| 24 | channel which is passed as part of the request. So the flow looks like: |
| 25 | |
| 26 | 1. The renderer creates a `UNIX DGRAM` socketpair. |
| 27 | 1. The renderer writes a request to file descriptor 4 with an `SCM_RIGHTS` |
| 28 | control message containing one end of the fresh socket pair. |
| 29 | 1. The renderer blocks reading from the other end of the fresh socketpair. |
| 30 | 1. A special "sandbox IPC" process receives the request, processes it and |
| 31 | writes the reply to the end of the socketpair contained in the request. |
| 32 | 1. The renderer wakes up and continues. |
| 33 | |
| 34 | The browser side of the processing occurs in |
| 35 | `chrome/browser/renderer_host/render_sandbox_host_linux.cc`. The renderer ends |
| 36 | could occur anywhere, but the browser side has to know about all the possible |
| 37 | requests so that should be a good starting point. |
| andybons | 3322f76 | 2015-08-24 21:37:09 | [diff] [blame] | 38 | |
| 39 | Here is a (possibly incomplete) list of endpoints in the renderer: |
| 40 | |
| Dominik Röttsches | ac24004 | 2018-07-06 09:52:40 | [diff] [blame] | 41 | ### localtime |
| andybons | 3322f76 | 2015-08-24 21:37:09 | [diff] [blame] | 42 | |
| Dominik Röttsches | ac24004 | 2018-07-06 09:52:40 | [diff] [blame] | 43 | `content/browser/sandbox_ipc_linux.h` defines HandleLocalTime which is |
| 44 | implemented in `sandbox/linux/services/libc_interceptor.cc`. |
| andybons | 3322f76 | 2015-08-24 21:37:09 | [diff] [blame] | 45 | |
| Dominik Röttsches | ac24004 | 2018-07-06 09:52:40 | [diff] [blame] | 46 | ### Creating a shared memory segment |
| andybons | 3322f76 | 2015-08-24 21:37:09 | [diff] [blame] | 47 | |
| Dominik Röttsches | ac24004 | 2018-07-06 09:52:40 | [diff] [blame] | 48 | `content/browser/sandbox_ipc_linux.h` defines HandleMakeSharedMemorySegment |
| 49 | which is implemented in `content/browser/sandbox_ipc_linux.cc`. |
