はじめに
Native Clientをいじるようになって、「Chromeの基本は押さえとかないと」いうことで「The Chromium Projects」のNative lient > 1: Getting Started:Background and Basicsを端折り気味にまとめてみた。まだ私自身理解していないので、誤っている部分はあるかもしれない。
原文: http://www.chromium.org/nativeclient/getting-started/getting-started-background-and-basicsChrome
Chromeはマルチプロセスのブラウザである。シングル・プロセスのブラウザと比較して強化されたセキュリティを提供する。
メインプロセスは"browser"と呼ぶ。"browser"は(Omniboxを含む)UIの実行・タブ管理・プラグイン実行管理を行う。"browser"はリソース(ファイル,ネットワーク,その他)へのアクセスおよび新たなプロセスを起動するための権限がある。
タブは分離された別のプロセス中に置かれる。そして領域ごとに共有される。これらは"renderer"プロセスと呼ぶ。"renderer"はHTMLレイアウトを解釈し、ビットマップ上にページを表示する。"renderer"はサンドボックス(外部サンドボックス)上で実行され、限定されたアクセス権限を持っている。"renderer"はファイルを開いたりネットワーク接続をしたりすることはできず、"browser"からの通信要求に対応する処理のみを行うことができる。 通信はIPCによって行われる。もし1つのタブが変な動きやクラッシュをしても残りのタブとブラウザは隔離されることをサンドボックス化された"renderer"は保証する。
プラグイン
プラグインはブラウザに新機能を追加する。プラグインはプラグインのコンテントをページに追加する時に読み込まれる。プラグインは予めバンドルされているか、利用者によってダウンロード・インストールされる。一般的なものとしては"Adobe Flush","Adobe Reader","Java"などがある。
一般的にプラグインはネットワークアクセスやファイルシステムにアクセスするので"renderer"プロセスのようにサンドボックス化されていない。なのでChromeは「プロセス外プラグイン」をサポートしている("browser"や"renderer"とはプロセスが分離される)。「プロセス外プラグイン」はIPCを通じて"browser"と"renderer"とやり取りする。Chromeは「プロセス内プラグイン」もサポートする。「プロセス内プラグイン」は"renderer"内で動作するので(IPCを使用しないので)高速なやり取りが可能である。「プロセス内プラグイン」はブラウザに静的に機能を追加するための統合メカニズムとしても使用されている。
Netscape Plugin API (NPAPI)
NPAPIはプラグインとブラウザ間のデータ交換のためのブラウザ互換APIである。NPAPIはChrome,Firefoxや他のブラウザで実装されている。ただしIEをのぞく(同様の技術であるActiveXのサポートをしていたが、今はやめている)。
他のシングル・プロセスのブラウザと違い、Chromeはプロセス外NPAPIプラグインをサポートしている。NPAPIをプロセス外で動かすことによりブラウザの安定性は増すが、安全性には問題が残る。Chrome上であってもNPAPIプラグインは新しいプロセスの起動とPC資源への完全なアクセスが可能だからである。
NPAPIはプラットフォーム非依存を意図しているが実際はそうではない。NPAPIは「ゆるい標準」であり、ブラウザ毎に微妙に実装が異なる。さらにいうとNPAPIはOSやブラウザの機能に依存してしまっている。
Pepper Plugin API(PPAPI)
PepperはNPAPIの可搬性とパフォーマンスの課題(特にプロセス外プラグインに関する)を解決するためにGoogleで開始された。最初は2D・3D・オーディオの機能を含む拡張を目指した。
最初のPepperAPIはブラウザベンダ・プラグイン開発者が容易に移行できるよう、NPAPIからの変更を最小限にするように設計された。この設計は実装され、Chrome5のNaClモジュールとして公開された。PepperAPIはインターフェースを改良するうちにNPAPIから逸脱してしまったのでその後再設計された。その改良されたインターフェースは"PPAPI"もしくは"Pepper2"としてChrome6で公開されるべきであった(が公開されなかった)。
ChromeではNPAPIプラグインはプロセス外(分離プロセス)としてのみ動作するけれども、Chrome5はプロセス内でのみPepper Pluginをサポートする。他の実験的な機能と同様に、Pepper Pluginをロードする方法はブラウザのコマンドラインのみである。将来的にはPepper PluginはNative Client内でのみサポートされるようになるだろう。
Native Client (NaCl)
Native Client(NaCl)はブラウザ中で信頼されていないネイティブ・コードをプラットフォーム非依存で安全に実行するためのサンドボックス技術である。NaClはゲームや大量データ解析や可視化などの大量の計算を必要とするアプリケーションをWebブラウザ上で実現する。NaClは安全性を損なうことなく、サーバ・クライアントPCのリソースやネットワークトラフィックを最適化することができる。
Native ClientはNative Client SDKを利用して作ることができる。
NaClは複数のブラウザに対応するため、NPAPI Pluginとしてスタートしている。
NaClは"service runtime"サブシステムを持っている。"service runtime"は限定されたシステムコール・リソースの抽象化を行い、NaClモジュールをホストから分離する。"service runtime"はPOSIXに似た環境を提供している。Naclモジュールはsel_ldr(secure ELF loader)により分離されたプロセスで実行される。sel_ldrプロセスは"SRPC over IMC"を通じてNacl pluginとやり取りする。
現在NaClはプロセス内PepperプラグインとしてChrome5で統合されている。NaClモジュールはPepper APIもしくは SRPCにより直接ブラウザとやり取りをする。統合の過程でsel_ldrプロセスを実行するのサンドボックスプラグインのための特別なサポートが付加されている。
「信頼される」・「信頼されない」
サンドボックスの存在下では、信頼されるコードはサンドボックスの外側で動作し、特権処理を実行できる。一方、潜在的に誤った振る舞いをしたり悪意があるソフトウェアとしてシステムから区別される、信頼されないコードはサンドボックスで囲いこまれ、実行を禁止される。
信頼されるか信頼されないかに関わらず、NaClコードはNaClサンドボックスの内部で動作する。サンドボックスを実装するコードは信頼される。サンドボックス自体のコードは信頼されない。信頼されないコードは限定された命令とアラインメントを守り、NaClによって検証可能なバイナリを出力するNaCl SDKもしくは他のコンパイラでビルドされる。NaClは信頼されていないコードが特権処理を行わないことを静的に確認する。
纏めると、プロセス外やサンドボックスの外側で実行される従来のNPAPIは信頼されると考えられる。Chromeサンドボックス内で動作するプロセス内PepperプラグインはNaCl(への操作?)に関して信頼される。(NaClの内部で実行しなくてはならない)プロセス外のプラグインは信頼されない。NaClのselldrプロセスは信頼され、信頼されないNaClモジュール(nexe)の代わりにChromeサンドボックスシステムコールを行うことができる。
<img src="http://www.chromium.org//rsrc/1278971287192/nativeclient/getting-started/getting-started-background-and-basics/nacldiagram.png" alt="image" />
http://www.chromium.org//rsrc/1278971287192/nativeclient/getting-started/getting-started-background-and-basics/nacl_diagram.png