By Marco Fioretti
WebAssembly（Wasm） は、すべてのブラウザが直接実行できるバイナリソフトウェア形式です。 安全に ほぼネイティブの速度で、任意のオペレーティングシステム（OS）で。ただし、その最大の約束は、最終的には同じように機能することです。 どこにでも、IoTデバイスやエッジサーバーから、モバイルデバイスや従来のデスクトップまで。この投稿では、これを実現するためのメインインターフェイスを紹介します。このシリーズの次の投稿では、同じインターフェイスのすでに利用可能な実際の実装とアプリケーションのいくつかについて説明します。
もう一度、移植性とは何ですか？
安全でポータブルであるためには、少なくともソフトウェアコードが必要です。
- ユーザーとプログラムが実際にできることだけを実行できることを保証します 持ってる 行う権利、および他のプログラムやユーザーに問題を引き起こさずにのみそれを行う
- これらの保証を宣言して適用するための、プラットフォームに依存しない標準のメソッド
従来、これらのサービスは、各言語の「システムコール」のライブラリによって提供されていました。これは、ソフトウェアプログラムがホストOSに低レベルまたは機密性の高いタスクを実行するように要求できる関数です。それらのライブラリが次のような標準に従う場合 POSIX、どのコンパイラも自動的にそれらをソースコードと組み合わせて、で実行できるバイナリファイルを生成できます。 いくつか OSとプロセッサの組み合わせ。
次のレベル：バイナリ互換性
システムコールは行うだけです ソースコード プラットフォーム間でポータブル。それらは便利ですが、それでも開発者にプラットフォーム固有の実行可能ファイルを生成するように強制します。多くの場合、ソースコードの多かれ少なかれ異なる組み合わせから生成されます。
代わりに、WebAssemblyは次のレベルに到達することを目指しています。必要な言語を使用し、それを1回コンパイルして、次のような1つのバイナリファイルを生成します。 ただ走れ、安全に、WebAssemblyを認識する任意の環境で。
Wasmがブラウザの外部で動作する必要がないもの
WebAssemblyはすでにすべての主要なブラウザーで「一度コンパイル」されるため、その範囲を拡大する最も簡単な方法は、すべてのターゲット環境に対して、WasmモジュールがFirefoxまたはChromeに期待するすべてを提供する完全な仮想マシン（ランタイム）を作成するように見えるかもしれません。
しかし、そのように動作します 本当に 複雑で、何よりも、多くの場合（IoTデバイスなど）、不可能ではないにしても、単に不要です。さらに、Wasmモジュールをセキュリティで保護する方法は、今日のブラウザのように万能のサンドボックスにダンプするよりも優れています。
ソリューション？仮想オペレーティングシステムとランタイム
完全にポータブルなWasmモジュールは、1つの実用的な例を挙げると、プラットフォームに依存するマシンコードを生成するシステムコールでのみWebカメラまたはWebサイトへのアクセスを記述できるようになるまで発生しません。
したがって、そのようなモジュールを持つための最も実用的な方法は、 どれか プログラミング言語は、 WebAssemblyシステムインターフェイス（WASI）プロジェクト：コードの記述とコンパイルのみ 1つ、明らかに仮想、 しかし、完全なオペレーティングシステム。
一方では、WASIはのすべての開発者に提供します Wasmランタイム エミュレートする単一のOS。一方、WASIは、すべてのプログラミング言語に、同じOSと通信するための1セットのシステムコールを提供します。
このように、10の異なるプラットフォームにロードした場合でも、 バイナリ 特定のWASI関数を呼び出すWasmモジュールは、それを起動したランタイムから、毎回異なるバイナリオブジェクトを取得します。しかし、これらのオブジェクトはすべて、まったく同じ方法でその単一のWasmモジュールと相互作用するため、問題にはなりません。
このアプローチは、WebAssemblyの最初のユースケース、つまりWebブラウザー内のJavaScript仮想マシンでも機能します。 WASI呼び出しを使用するWasmモジュールを実行するには、それらのマシンは対応するライブラリのJavaScriptバージョンのみをロードする必要があります。
このOSレベルのエミュレーションは、単純なサンドボックス化よりも安全です。 WASIを使用すると、すべてのランタイムが、仕様に準拠している限り、さまざまなセキュリティ特権を使用して、各システムコールのさまざまなバージョンを実装できます。次に、そのランタイムは、起動するすべてのWasmモジュールのすべてのインスタンスを個別のサンドボックスに配置し、その特定のインスタンスが実際に必要とする関数の最小かつ最小特権の組み合わせのみを含めることができます。
この「最小特権の原則」、または「機能ベースのセキュリティモデル「、WASIのいたるところにあります。 WASIランタイムは、サンドボックスに「開く」システムコールのインスタンスを渡すことができます。このインスタンスは、特定のファイルまたはフォルダーのみを開くことができます。 事前選択 ランタイム自体によって。これは、従来のファイルパーミッションやchrootシステムでさえ可能であるよりも、プログラムが実行できることをより堅牢で、はるかにきめ細かく制御できます。
コーディングに関しては、ファイル、フォルダ、ネットワーク接続、時間の基本的な管理などの機能は、ほとんどすべてのプログラムで必要です。したがって、対応するWASIインターフェースは、同等のPOSIXインターフェースと可能な限り類似して設計されており、すべてが1つの「wasi-core」モジュールにパッケージ化されており、すべてのWASI準拠ランタイムに含まれている必要があります。
のバージョン libc 標準Cライブラリ、書き直されたusi wasi-core関数は、すでに利用可能であり、 その開発者によると、すでに「十分に安定しており、多くの目的に使用できます」。
WASIに含まれる、または今後含まれる予定の他のすべての仮想インターフェイスは、ランタイムにそれらすべてをサポートさせることなく、標準化され、個別のモジュールとしてパッケージ化されます。次の記事では、これらのWASIコンポーネントのいくつかが今日すでにどのように使用されているかを見ていきます。
