- ブラウザURL入力今ここ
- DNS名前→IP
- ルータ経路選択
- ロードバランサ振り分け
- Nginx受け口
- アプリ処理
- DB保存
第9週でプロセスごとにアドレス空間が分かれる仕組みを、第13週でアプリがカーネルに依頼する仕組みを見ました。今回は、その2つがブラウザの内部でもう一度使われている様子を扱います。
まず結論
ブラウザが重いのは、プロセスをたくさん作るからです。しかしそれは無駄ではなく、**OSが過去にやったことをWebにもう一度適用した結果**です。公式は「memory protection and access control が OS にもたらした利益を、Webブラウジングにもたらす」と書いています。
分けたうえで、レンダラからは**ほとんど何もできなくします**。自由に使えるのは CPU サイクルとメモリだけ。ではファイルの読み書きはどうするのか——**特権を持つ側に代行してもらいます**。第13週のシステムコールと、まったく同じ形です。
Chromium のレンダラ(Webページを処理するプロセス)が、サンドボックスの中で自由に使えるものは何でしょうか。
当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。
出発点は「完璧なものは作れない」
公式文書 Multi-process Architecture は、設計の説明ではなく諦めから始まります。
It's nearly impossible to build a rendering engine that never crashes or hangs. It's also nearly impossible to build a rendering engine that is perfectly secure.
落ちないものも、完全に安全なものも作れない。ならば落ちても被害が広がらない形にするしかありません。そしてその形には前例がありました。
Modern operating systems are more robust because they put applications into separate processes that are walled off from one another. A crash in one application generally does not impair other applications or the integrity of the operating system, and each user's access to other users' data is restricted. Chromium's architecture aims for this more robust design.
第9週で見たとおり、プロセスごとに変換表が別々だから、表に載っていない場所へは到達手段が無い——あれが「walled off」の実体です。ブラウザはそれを借りてきました。
In some ways, this brings to web browsing the benefits that memory protection and access control brought to operating systems.
新しい発明ではありません。 OSが数十年前に済ませた解決を、Webという別の層にもう一度当てただけです。
Chromium が複数プロセスにした理由を、公式 [MPA] はどんな比喩で説明していますか。
プロセスの名前は、公式の原語で覚える
公式が使っている呼び名はこうです。
We refer to the main process that runs the UI and manages renderer and other processes as the "browser process" or "browser." Likewise, the processes that handle web content are called "renderer processes" or "renderers."
さらに他の部品も分かれています。
For example, it now has a separate GPU process, network service, and storage service. Sandboxed utility processes can also be used for small or risky tasks
呼び名 原文での語browser process (browser) processrenderer processes (renderers) processGPU process processnetwork / storage service ← process とは書かれていないSandboxed utility processes process
4行目だけ service です。「5種類のプロセスがある」と並べた瞬間、原文から離れます。表を整えると原語の凸凹が消える——引用が壊れる典型的な入口です。
分けた先で、ほとんど何もできなくする
分けるだけでは足りません。レンダラは外から来たデータを解釈する係なので、乗っ取られる前提で扱われます。
The only resources sandboxed processes can freely use are CPU cycles and memory.
ディスクに書けず、自分のウィンドウも出せません。その効果は限定的だと公式自身が書いています。
The sandbox limits the severity of bugs in code running inside the sandbox.
無くすのではなく、深刻度を下げる。そして限界も明記されています。
The sandbox cannot provide any protection against bugs in system components such as the kernel it is running on.
サンドボックス化されたレンダラが、禁止されているはずの仕事(ファイル保存など)を実現する方法はどれですか。
システムコール(第13週)
アプリはユーザーモードで動き、ハードウェアに直接触れられません。ファイルを読むにはカーネルに依頼します。依頼の形にすることで、カーネル側に正当性を確認する余地が生まれます。第13週で見たとおり、これは関数呼び出しに似て見えて、CPUの特権レベルが切り替わる別物でした。
できない側 アプリ(ユーザーモード)特権のある側 カーネル頼み方 システムコール = 検査の置き場所
サンドボックスの broker / target
レンダラは CPU サイクルとメモリしか自由に使えません。ではファイル保存はどうするのか。公式は “A more privileged process can use these channels to do certain actions on behalf of the sandboxed process.” と書いています。特権のある側が代わりに実行します。Chromium では “the broker is always the browser process” です。
できない側 renderer(target)特権のある側 browser process(broker)頼み方 開かれた通信路 = 検査の置き場所
OSのシステムコールと、ブラウザのサンドボックス。層はまったく違いますが、共通している構造は何でしょうか。
どちらも「禁止したあと、その仕事をどう成立させるか」を同じやり方で解いています。
この章のまとめ
- 出発点は「落ちない・完全に安全なレンダリングエンジンはほぼ作れない」という前提。
- 解決は新発明ではなく、OSの再適用。公式の言葉で memory protection and access control をWebにもたらすこと(第9週)。
- 原語は browser process / renderer processes / GPU process / Sandboxed utility processes。network と storage は "service" と書かれており、揃えて「プロセス」と書くと原文から離れる。
- サンドボックスの中で自由に使えるのは CPUサイクルとメモリだけ。バグを無くすのではなく深刻度を下げる。カーネル側のバグには保護を提供できないと明記。
- できない仕事は broker(= browser process)に代行してもらう。第13週のシステムコールと同じ「禁止+代行」。
- サンドボックス(システムからの隔離)と Site Isolation(サイト間の隔離)は別物。 次回は後者を扱う。
自分の現場で確かめる
読んだだけでは身につきません。手元の環境で実際に見てみてください。
理解度チェック
読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。
「Chromium には browser process・renderer process・GPU process・network process・storage process がある」という説明を、公式の記述に照らして評価してください。
用語集(4語)
- browser process(略 browser)
- 公式の定義は “the main process that runs the UI and manages renderer and other processes”。UIを動かし、他のプロセスを管理する中心のプロセス。サンドボックスの broker でもある。
- renderer processes(略 renderers)
- 公式の定義は “the processes that handle web content”。HTMLの解釈とレイアウトには Blink を使う。サンドボックスの中で動く側(target)。
- broker と target
- 公式の言い方は “one that is a privileged controller known as the broker, and one or more sandboxed processes known as the target”。Chromium では broker は常に browser process。
- サンドボックス
- 目的は “to provide hard guarantees about what ultimately a piece of code can or cannot do no matter what its inputs are”。**システムからの隔離**であって、サイト間の隔離ではない。