ac24004e38
This is a reland of https://chromium-review.googlesource.com/c/chromium/src/+/1109964 Tbr'ing previous reviewers from that CL as the exact change has been previously reviewed there. The revert was done manually in response to flakiness of viz_browser tests in MSAN. See issue https://crbug.com/860349 - my analysis is in issue https://crbug.com/860445 where I disable this test. In short, I believe my CL exposed a previously existing race condition in that test. Instead of Chromium IPC macro-defined messages or Mojo, Chrome on Linux uses hand-pickled IPC messages through a special purpose file descriptor to send messages from the renderer to the browser host in order to access FontConfig for font matching and font fallback. This system is described in docs/linux_sandbox_ipc.md. For the "Font Matching by Full Font Name / PS Name" effort, see issue 828317, additional out of process font methods are needed. Instead of adding them to this legacy hand-written IPC, we modernize the Linux Sandbox IPC mechanism and upgrade it to using Mojo interface definitions and a service architecture, in which a font service running in an unsandboxed utility process answers FontConfig requests from the renderer. Previous CLs [1], [2] prepared the Font Service to have testing and additional font fallback and render-style-for-strike methods. Now we can move Blink over to using this Mojo interface and remove the traditional sandbox IPC handlers since we do not use the file descriptor based IPC anymore for FontConfig acces. For more details, please refer to the design doc in issue 839344. [1] https://chromium-review.googlesource.com/c/chromium/src/+/1091754 [2] https://chromium-review.googlesource.com/c/chromium/src/+/1087951 Bug: 855021 Change-Id: I74663c5685a7797089e4d69354453146c245e20a Tbr: skyostil@chromium.org, michaelpg@chromium.org, rsesek@chromium.org, halliwell@chromium.org, thestig@chromium.org, piman@chromium.org, eae@chromium.org Reviewed-on: https://chromium-review.googlesource.com/1127028 Commit-Queue: Dominik Röttsches <drott@chromium.org> Reviewed-by: Dominik Röttsches <drott@chromium.org> Cr-Commit-Position: refs/heads/master@{#572930}
50 lines
2.3 KiB
Markdown
50 lines
2.3 KiB
Markdown
# Linux Sandbox IPC
|
|
|
|
The Sandbox IPC system is separate from the 'main' IPC system. The sandbox IPC
|
|
is a lower level system which deals with cases where we need to route requests
|
|
from the bottom of the call stack up into the browser.
|
|
|
|
The motivating example used to be Skia, which uses fontconfig to load
|
|
fonts. Howvever, the OOP IPC for FontConfig was moved to using Font Service and
|
|
the `components/services/font/public/cpp/font_loader.h` interface.
|
|
|
|
These days, only the out-of-process localtime implementation as well as
|
|
an OOP call for making a shared memory segment are using the Sandbox IPC
|
|
file-descriptor based system. See `sandbox/linux/services/libc_interceptor.cc`.
|
|
|
|
Thus we define a small IPC system which doesn't depend on anything but `base`
|
|
and which can make synchronous requests to the browser process.
|
|
|
|
The [zygote](linux_zygote.md) starts with a `UNIX DGRAM` socket installed in a
|
|
well known file descriptor slot (currently 4). Requests can be written to this
|
|
socket which are then processed on a special "sandbox IPC" process. Requests
|
|
have a magic `int` at the beginning giving the type of the request.
|
|
|
|
All renderers share the same socket, so replies are delivered via a reply
|
|
channel which is passed as part of the request. So the flow looks like:
|
|
|
|
1. The renderer creates a `UNIX DGRAM` socketpair.
|
|
1. The renderer writes a request to file descriptor 4 with an `SCM_RIGHTS`
|
|
control message containing one end of the fresh socket pair.
|
|
1. The renderer blocks reading from the other end of the fresh socketpair.
|
|
1. A special "sandbox IPC" process receives the request, processes it and
|
|
writes the reply to the end of the socketpair contained in the request.
|
|
1. The renderer wakes up and continues.
|
|
|
|
The browser side of the processing occurs in
|
|
`chrome/browser/renderer_host/render_sandbox_host_linux.cc`. The renderer ends
|
|
could occur anywhere, but the browser side has to know about all the possible
|
|
requests so that should be a good starting point.
|
|
|
|
Here is a (possibly incomplete) list of endpoints in the renderer:
|
|
|
|
### localtime
|
|
|
|
`content/browser/sandbox_ipc_linux.h` defines HandleLocalTime which is
|
|
implemented in `sandbox/linux/services/libc_interceptor.cc`.
|
|
|
|
### Creating a shared memory segment
|
|
|
|
`content/browser/sandbox_ipc_linux.h` defines HandleMakeSharedMemorySegment
|
|
which is implemented in `content/browser/sandbox_ipc_linux.cc`.
|