WASMのシステムインタフェースの現状と課題
導入
WASM単体ではほとんど何もすることができず、実用的な処理をするには外部APIを明示的にimportして用いる必要がある。WASM Runtimeはimportされた関数以外使われないことを保証するため、アプリケーションを動かすのに必要最小限のAPIだけ使用を許可することができる。これがWASMがセキュアといわれる理由の一つであるが、この安全性は「外部APIで何ができるか」に依存している。例えばsyscallのような任意のシステムコールを実行するAPIがあれば、明らかに脆弱である。このため、WASI(WebAssembly System Interface)の標準化が進められている。
課題
WASMのDesign Goalsには「Safe」の他に「Portable」がある。WASMは仮想CPUの命令セットであり、特定のCPUに依存しない。WASM Runtimeがそれぞれの環境向けに翻訳して実行するため、WASMバイナリはPortableである。(以下は上の記事からの引用)
WASIはシステムリソースへのアクセスを提供するため、その役割はOSが提供するシステムコールと同じである。WASMバイナリがPortableであるためには、この “システムコール” はOSに依存したものであってはならない。さらに、そのインタフェースはセキュリティを考えて注意深く定義する必要がある。
問題はこれには時間がかかることである。実際、WASIの仕様策定が遅いため、Wasmerは独自にWASIXというインタフェースを定義している。さらに最近、WALIという、WASIとは別のシステムインタフェースが出てきた。これはLinuxのシステムコールをそのままWASMの世界に持ってくるものである。論文では高レベルなAPIでは合意をとるのが難しいため、より低レベルなAPIを用意して、そのうえでWASIやWASIXのような高レベルAPIを実装することが提案されている。
考察
WASMのPortabilityは 「皆が同じものを使う」 ことで実現される。WASIの目的はシステムインタフェースを標準化することだったが、WASIXやWALIが出てきてしまった。汎用だったはずのWASMバイナリは、既にランタイム依存になりつつある。
WASIを定義したところで、それが使われなければ意味がない。仕様が大きくなれば合意を取るのが困難になるため、仕様は必要最小限のものである必要がある。つまりWASIは必用最小限で、かつOSに依存しない汎用的なインタフェースを目指す必要がある。
現状、WASIはどちらの条件も満たしていない。WASIの大部分はPOSIXを前提としたインタフェースになっているし、仕様もどんどん大きくなることが予想される。アプリケーションが必要とするすべてのインタフェースについて仕様を定義し、合意を取ることはかなり難しいことに思える。(しかもそのインタフェースはセキュリティを考えた"使いにくい"ものなのだ)
WASIXやWALIのような独自APIが沢山生まれてしまうと、WASMの「Portable」,「Safe」という特徴が完全に失われ、WASM+WASIが廃れる恐れがある。WASM+WASIが目指す世界はとても魅力的だが、その実現にはまだまだ課題があると言わざるを得ない。
Discussion