0xDEADBEAF

今朝目覚めたら、Google が という面白そうなものを出していたので、 (PDF) をざっと読んでみました。で思ったのは、これは Google の 分散 OS ミドルウェア なのだな、ということ。

以下、自分が受け取ったことを書きます。ちゃんと知りたい方は、論文をあたってください。(参考: id:amachang による実践エントリ)

かんたんなおさらい

Native Client とは?

ブラウザの中で、x86のネイティブコードを実行できるようにする仕組みです。

何がうれしいの?

• 実行速度。スピード! とにかくもっとスピードを!!
• マシンの機能をフルに使える。ファイルアクセスも、マルチスレッドも、SIMDでさえも書けるよ!
• それでいてセキュア: 多段サンドボックス方式で、危険なことができないようになってます。

例として挙げられているのは、写真をあつかうWebアプリ。JS+HTMLでユーザインターフェイスを書いておいて、スピードが必要な画像処理はローカルのネイティブコードでやるという処理分担です。 ユーザは JS/HTML/ネイティブコード の3つを書くことになりますね。

それに加えて、Native Client 間の通信もサポートされています。先ほどの写真アプリだと、画像処理に加えてローカルストレージへのアクセスを提供するライブラリと組み合わせる、なんてことも難なくできるという。

みどころ

ランタイムシステムのところでは、とにかく OSっぽさ が随所にでてきますね。マイクロカーネルみたいなもんだよ、とか IPC とか UDP ライクな通信とかマルチスレッドとか。sbrk(), mmap(), malloc(), free() みたいな API を提供するとか。それでいて、 Windows/Mac/Linux といったマルチプラットフォームで動きますと。なので、ぼくはこれこそが Google OS なのだと思いました。下位に存在する OS レイヤをラップするような、それでいて低レベルなタスクをこなすミドルウェア。

Intel TBB (Threading Building Blocks) でさえ移植できたよ! というのもおもしろかったです。

どうやってセキュアにするのか

2段階のサンドボックスでアプリを閉じ込めます (3) 。Inner (HW, x86 アーキテクチャの機能を利用) と Outer (SW, ptrace とか使う) の2つ。ここの実装がバイナリハックス的に面白いですね。実行できる命令の種類に制限をつけるとか、GCCに手を入れて出力する機械語をサンドボックス用にするとかそういうあたり。論文読む方はこのへんを重点的にどうぞ。

3.1 の Inner Sandbox の性能について述べてるとこが楽しいですね。ユーザのコードがSandbox規約に違反してないかをチェックする Validator が、たった 500 statements の C コードであり、コンパイルすると 6000 バイトでしかないよ、と胸を張っているあたりにぐっときます。

Java とか Flash とかとどう違うの?

より低レイヤなことができる、ということなのかと思いました。 Java は思想的に近いだろうけど、さらに泥臭いことができるという。あと、 Java とか Flash だと、中間に VM というレイヤがあるのですが、 Native Client ではそこをすっとばしていきなりネイティブをさわりにいくというあたりが Google っぽいなと (参考: Google Chrome)。

そもそも、記述言語として使えるのが GCC toolchain が提供するものなので (3.6) 、まあ C/C++ になりますよね。そんなレベルでゴリゴリ書いたコードが Web アプリで動かせるという。データベースと回線の太さに律速されるようなふつうの Web アプリ屋さんにはオーバースペックになるかもしれませんが、 Goolge みたいな用途ではバリバリ使うのかしら。

疑問が残るところ

2.1 では、 UI を書く JS+HTML コードと .nacl なネイティブコードはプラットフォーム間でポータブルとあるのですが、その後の章でそれについて触れられていないのが気になりました。gcc toolchain を使うんだし、 Windows とかどうするんだろうな、と。そのままのバイナリでいけるのかな。

2008-12-10 01:33 追記: takuma104さんのブコメ によると、同じバイナリ (ELF フォーマット) が Mac でも Windows でもそのまま動いたとのこと。3.2 で書かれている、セキュア ELF ローダ (sel_ldr) とその先にあるランタイムで、プラットフォーム間の差異を吸収しているのでしょう。

あと、評価のところ (4.3) で、 H.264 decoder を Native Client のコードと元々のコードとで比較しているのですが、実測値がでてこず

Performance of the original and NaCl versions were comparable and limited by video frame-rate

としか書かれていなかったのが寂しかったです。

思うところ

• ブラウザの中で動く言語処理系とかを簡単につくれるのではないでしょうか。これまで JavaScript で実装した処理系とかいくつかありましたけれど、そういうのがもっと簡単につくれる (というか、移植できる) ようになる気が。
• GPGPUと組み合わせてみてもおもしろそうですね。ちょうど OpenCL 1.0 も出たところだし。
• 練習問題: Gears との関係は?

---

Native Client が流行るかといわれるとそうでもないかなーと思うんですが、やはり Google のインフラ技術はおもしろいですね。