Mozillaの3月27日、WebAssemblyシステムインターフェイス（WebAssemblyシステムインターフェイス）であるWASIの標準化の開始を発表しました。



理由： WASMはすべてのマシンで同じコードを実行するための高速でスケーラブルで安全な方法を提供するため、開発者はWebAssemblyをブラウザーの外部で使用し始めました。 しかし、そのような開発のための強固な基盤はまだありません。 ブラウザの外部では、システム、つまりシステムインターフェイスと通信するための何らかの方法が必要です。 しかし、WebAssemblyプラットフォームにはまだありません。



内容： WebAssemblyは、物理マシンではなく概念マシンのアセンブラーです。 さまざまなアーキテクチャで動作するため、概念OSが異なるオペレーティングシステムで動作するにはシステムインターフェイスが必要です。



これがWASIです。WebAssemblyプラットフォームのシステムインターフェイスです。



私たちは、最大限の移植性とセキュリティを備えたWebAssemblyの真の仲間となるシステムインターフェイスの作成に努めています。



Who： WebAssembly開発チームの一部として、 WASIを標準化するためにサブグループを編成しました 。 私たちはすでに興味のあるパートナーを集めており、新しいパートナーを探しています。



私たち、パートナー、サポーターがこれを重要と考える理由は次のとおりです。



Mozilla R＆Dディレクター、Sean White：

「WebAssemblyは、人々が新しいタイプの魅力的なコンテンツを配信する方法をすでに変えています。これは、コンテンツ開発者とクリエイターを支援します。 これまで、すべてがブラウザーを介して機能していましたが、WASIを使用すると、さまざまな場所でより多くのユーザーとデバイスがWebAssemblyの恩恵を受けることになります。

タイラー・マクマレン、CTO Fastly：

「WebAssemblyは、エッジクラウドでコードを迅速かつ安全に実行するためのプラットフォームであると考えています。 異なる環境（エッジとブラウザー）にもかかわらず、WASIのおかげで、各プラットフォームにコードを移植する必要はありません。

マイルズボリンズ、ノード運営委員会のCTO：

「WebAssemblyは、移植性とセキュリティを維持しながら、ネイティブに近い速度を実現し、CやC ++などの他の言語で記述されたコードを再利用するというNodeの最大の問題の1つを解決できます。 WASI標準化は、これに向けた最初のステップです。」

noriの共同設立者、ロリ・ヴォス：

「Npmは、ネイティブコードをサーバー側のJavaScriptアプリケーションで実行するのがはるかに簡単になるため、npmエコシステムのWebAssemblyの可能性に非常に興奮しています。 このプロセスの結果を楽しみにしています。」

これは大きなイベントです！



現在、3つのWASI実装があります。

• wasmtime 、Mozilla WebAssemblyランタイム
  
  
• Lucet 、Fastly WebAssemblyランタイム
  
  
• ポリフィルブラウザー

実際のWASIデモンストレーション：





次に、このシステムインターフェースの動作方法に関するMozillaの提案について説明します。

システムインターフェイスとは何ですか？

Cのような言語は、システムリソースへの直接アクセスを提供すると言います。 しかし、これは完全に真実ではありません。 ほとんどのシステムでは、これらの言語はファイルを開いたり作成したりすることなどには直接アクセスできません。 どうして？



これらのシステムリソース（ファイル、メモリ、ネットワーク接続）は、安定性とセキュリティにとって重要すぎるためです。



あるプログラムが別のプログラムのリソースを誤って破壊すると、クラッシュを引き起こす可能性があります。 さらに悪いことに、プログラム（またはユーザー）が他の人のリソースに特に侵入した場合、機密データを盗む可能性があります。







したがって、リソースにアクセスできるプログラムとユーザーを制御する方法が必要です。 長い間、システム開発者はこのような制御を提供する方法を考案しました：保護リング。



保護リングを使用すると、OSは基本的にシステムリソースの周りに保護バリアを設定します。 これがコアです。 ファイルの作成、ファイルのオープン、ネットワーク接続のオープンなどの操作を実行できるのは、それだけです。



ユーザープログラムは、ユーザー空間と呼ばれるカーネル内で実行されます。 プログラムがファイルを開きたい場合は、カーネルを要求する必要があります。







これは、システムコールの概念が生じる場所です。 プログラムがカーネルに何らかの操作を要求する必要がある場合、システムコールを送信します。 カーネルは接続しているユーザーをチェックし、このファイルにアクセスする許可があるかどうかを確認します。



ほとんどのデバイスでは、システムリソースにアクセスする唯一の方法はシステムコールを使用することです。







オペレーティングシステムは、システムコールへのアクセスを提供します。 しかし、各OSに独自のシステムコールがある場合、異なるバージョンのコードを記述する必要はありませんか？ 幸いなことにそうではありません。 この問題は、抽象化を使用して解決されます。



ほとんどの言語には標準ライブラリがあります。 コーディングの際、プログラマは自分がどのシステム用に書いているかを知る必要はありません。 インターフェースを使用するだけです。 次に、コンパイル時に、ツールチェーンは、どのシステムにどのインターフェイス実装を使用するかを選択します。 この実装は、オペレーティングシステムのAPIの関数を使用するため、固有です。



これは、システムインターフェイスの概念が現れる場所です。 たとえば、Windowsマシン用にprintf



をコンパイルすると、Windows APIが使用されます。 MacまたはLinux用にコンパイルされている場合、POSIXを使用します。







ただし、これはWebAssemblyに問題を引き起こします。 ここでは、コンパイル中でもプログラムを最適化するOSがわかりません。 したがって、WebAssemblyの標準ライブラリの実装内で、1つのOSのシステムインターフェイスを使用することはできません。







WebAssemblyは、実際のマシンではなく、 概念的なマシンのアセンブラーであると既に述べました 。 同様に、WebAssemblyには、実際のOSではなく概念のためのシステムインターフェイスが必要です。



ただし、このシステムインターフェイスがなくても、ブラウザーの外部でWebAssemblyを実行できるランタイムが既にあります。 彼らはどうやってそれをしますか？ 見てみましょう。

WebAssemblyはブラウザ外でどのように動作しますか？

WebAssemblyコードを生成する最初のツールはEmscriptenでした。 特定のOSシステムインターフェイスであるPOSIXをWeb上でエミュレートします。 これは、プログラマが標準Cライブラリ（libc）の関数を使用できることを意味します。



このため、Emscriptenは独自のlibc実装を使用します。 これは2つの部分に分かれています。最初の部分はWebAssemblyモジュールにコンパイルされ、もう1つは「JS-glue」コードで実装されます。 このJSグルーは、OSと通信しているブラウザーに呼び出しを送信します。







初期のWebAssemblyコードのほとんどは、Emscriptenでコンパイルされています。 したがって、人々がブラウザなしでWebAssemblyを実行したいと思うようになったとき、彼らはEmscriptenコードを実行し始めました。



したがって、これらのランタイムでは、JS-glueコードに含まれていたすべての関数に対して独自の実装を作成する必要があります。



しかし、問題があります。 JSグルーコードによって提供されるインターフェイスは、標準またはパブリックインターフェイスとしても設計されていません。 たとえば、通常のAPIでread



ように呼び出すには、JSグルーコードは_system3(which, varargs)



呼び出し_system3(which, varargs)



使用します。







最初のパラメーターは、名前の番号と常に一致する整数です（この例では3）。



2番目のパラメーターvarargs



、 varargs



リストします。 varargs



数が異なるため、 varargs



と呼ばれます。 ただし、WebAssemblyでは、可変数の引数を関数に渡すことはできません。 そのため、それらは線形メモリを介して送信されますが、これは安全ではなく、レジスタよりも低速です。



ブラウザのEmscriptenの場合、これは正常です。 しかし、今ではランタイムはこれを事実上の標準と見なし、独自のバージョンのJSグルーを実装しています。 POSIXエミュレーションレイヤーの内部詳細をエミュレートします。



これは、Emscripten制約が与えられると理にかなっているコードを再実装する（たとえば、引数をヒープ値として渡す）ことを意味しますが、これらのランタイム環境にはそのような制約はありません。







今後数十年にわたってWebAssemblyエコシステムを構築する場合、松葉杖ではなく強固な基盤が必要です。 これは、実際の標準がエミュレーションエミュレーションであることを意味します。



しかし、この場合に適用される原則は何ですか？

WebAssemblyシステムインターフェースはどの原則に従うべきですか？

WebAssemblyの2つの基本原則：

• 携帯性
  
  
• 安全性

私たちはブラウザを超えていますが、これらの重要な原則を保持しています。



ただし、POSIXアプローチとUnixアクセス制御システムでは、望ましい結果が得られません。 問題が何であるかを見てみましょう。

移植性

POSIXは、ソースコードの移植性を提供します。 異なるコンピューター用に異なるバージョンのlibcを使用して同じソースコードをコンパイルできます。







しかし、WebAssemblyはそれを超えなければなりません。 たくさんの異なるシステムで実行するために一度コンパイルする必要があります。 ポータブルバイナリが必要です。







これにより、コードの配布が簡単になります。



たとえば、ネイティブノードモジュールがWebAssemblyで記述されている場合、ユーザーはネイティブモジュールを使用してアプリケーションをインストールするときにnode-gypを実行する必要がなく、開発者は多数のバイナリファイルを構成および配布する必要がありません。

安全性

コードがオペレーティングシステムに入力または出力を要求すると、OSは通常、所有権とグループに基づいたアクセス制御システムを使用して、この操作のセキュリティを評価する必要があります。



たとえば、プログラムはファイルを開くように要求します。 ユーザーには、アクセスできる特定のファイルセットがあります。



ユーザーがプログラムを起動すると、そのユーザーに代わってプログラムが起動します。 ユーザーがファイルへのアクセス権を持っている場合-ユーザーがその所有者であるか、ファイルへのアクセス権を持つグループの一部である場合-プログラムは同じアクセス権を持ちます。







これは、多くの人が1台のコンピューターで作業し、管理者がソフトウェアを制御していた昔は理にかなっていたユーザーを互いに保護します。 そして、主な脅威は、ファイルを見ている他のユーザーでした。



すべてが変わりました。 現在、システムは通常シングルユーザーですが、信頼性が不明なサードパーティのコードを使用しています。 現在、主な脅威は、自分で実行するコードにあります。



たとえば、アプリケーションのライブラリの場合、新しいメンテナが開始されています（オープンソースの場合がよくあります）。 彼は誠実な活動家かもしれません...または侵入者かもしれません。 また、システムにアクセスできる場合（たとえば、ファイルを開いてネットワーク経由で送信する機能）、このコードは大きな損害を引き起こす可能性があります。





疑わしいアプリケーション ：私はユーザーBobで働いています。 彼のビットコイン財布を開けてもいいですか？

コア ：ボブの？ もちろん！

疑わしいアプリ ：すばらしい！ ネットワーク接続はどうですか？



これが、サードパーティライブラリの使用が危険な理由です。 WebAssemblyは、サンドボックスを介した別の方法でセキュリティを提供します。 ここでは、コードはOSと直接通信できません。 しかし、システムリソースにアクセスする方法は？ ホスト（ブラウザーまたはwasmランタイム）は、コードが使用できる機能をサンドボックス化します。



これは、ホストがプログラムによってプログラムの機能を制限することを意味し、ユーザーに代わって単に行動することを許可せず、完全なユーザー権限を持つシステムコールを引き起こします。



サンドボックスを単独で使用してもシステムは安全になりません。ホストはすべての機能をサンドボックスに転送できますが、その場合は保護が提供されません。 しかし、サンドボックスは、ホストがより安全なシステムを構築するための少なくとも理論的な機会を提供します。





WA ：OSとやり取りするための安全なおもちゃ（safe_write、safe_read）があります。

疑わしいアプリケーション ：いまいましい...ネットワークへの私のアクセスはどこですか？



どのシステムインターフェイスでも、これらの2つの原則に従う必要があります。 移植性はソフトウェアの開発と配布を容易にし、ホストとユーザーを保護するツールが絶対に必要です。

そのようなシステムインターフェースはどのように見えるべきですか？

これら2つの重要な原則を考えると、WebAssemblyシステムインターフェイスはどうあるべきでしょうか？



これは標準化プロセスで確認します。 ただし、開始の提案があります。

• 標準インターフェイスのモジュールセットの作成
  
  
• まず、wasi-coreコアモジュールを標準化することから始めましょう。

wasi-coreには何が含まれますか？ これらはすべてのプログラムに必要な基本です。 このモジュールは、ファイル、ネットワーク接続、クロック、乱数など、POSIXのほとんどの機能をカバーします。



基本的な機能の多くは、非常によく似たアプローチを必要とします。 たとえば、POSIXファイル指向のアプローチは、オープン、クローズ、読み取り、および書き込みのシステムコールで提供され、他のすべては上記の補完です。



しかし、wasi-coreはすべてのPOSIX機能をカバーしているわけではありません。 たとえば、プロセスの概念はWebAssemblyに明確に適合しません。 さらに、すべてのWebAssemblyエンジンがfork



などのプロセス操作をサポートする必要があることは明らかです。 しかし、 fork



標準化も可能にしたいと考えています。







Rustのような言語は、標準ライブラリでwasi-coreを直接使用します。 たとえば、Rustからのopen



は、 __wasi_path_open



を呼び出してWebAssemblyにコンパイルするときに実装されます。



CおよびC ++の場合、 wasi-sysrootを作成しました。これは、wasi-core関数の観点からlibcを実装します。







ClangなどのコンパイラーはWASI APIと対話でき、RustコンパイラーやEmscriptenなどの完全なツールチェーンがシステム実装の一部としてWASIを使用することを期待しています。



カスタムコードはこれらのWASI関数をどのように呼び出しますか？



コードが実行されるランタイムはwasi-core関数を渡し、オブジェクトをサンドボックスに配置します。







これは移植性を提供します。これは、各ホストがそのプラットフォーム専用のwasi-core実装を持つことができるためです。MozillaWasmtimeやFastly LucetなどのWebAssemblyランタイムからNode、さらにはブラウザまで。



また、ホストがソフトウェアベースでサンドボックスに転送するwasi-core機能、つまり許可するシステム呼び出しを選択するため、信頼性の高い分離も提供されます。 これがセキュリティです。







WASIは、認証ベースのセキュリティ概念をシステムに導入することにより、セキュリティを強化および拡張します。



通常、コードでファイルを開く必要がある場合は、行にパス名を指定してopen



を呼び出します。 次に、OSは（プログラムを起動したユーザーの権利に基づいて）コードにそのようなアクションの権利があるかどうかをチェックします。



WASIの場合、ファイルにアクセスする関数を呼び出すときは、ファイル自体またはファイルを含むディレクトリのアクセス許可が関連付けられているファイル記述子を渡す必要があります。



したがって、誤って/etc/passwd



を開くように要求するコードを持つことはできません。 代わりに、コードは独自のディレクトリでのみ機能します。







これにより、これらのシステムコールの機能が制限されるため、さまざまなシステムコールを分離されたコードに安全に解決できます。



そして、各モジュールで。 デフォルトでは、モジュールはファイル記述子にアクセスできません。 ただし、あるモジュールのコードにファイル記述子がある場合、他のモジュールで呼び出される関数に渡すことができます。 または、より限定されたバージョンのファイル記述子を作成して、他の関数に渡します。



このようにして、ランタイムはアプリケーションが最上位コードで使用できるファイル記述子を渡し、ファイル記述子は必要に応じてシステムの残りの部分に分散されます。







これにより、WebAssemblyは最小特権の原則に近づき、モジュールはそのジョブを実行するために必要な最小限のリソースセットにのみアクセスできます。



この概念は、CloudABIやCapsicumのように、特権ベースのセキュリティに基づいています。 これらのシステムの問題の1つは、コードの移植性が難しいことです。 しかし、この問題は解決できると信じています。



コードが既に相対ファイルパスでopenat



を使用している場合、コードのコンパイルは機能します。



コードでopen



使用さopen



おり、openatスタイルの移行が非常に激しい場合、WASIは増分ソリューションを提供します。 libpreopenを使用して、アプリケーションが合法的にアクセスできるファイルパスのリストを作成します。 次に、これらのパスでのみopen



使用します。

次は？

wasi-coreは良いスタートだと信じています。 WebAssemblyの移植性とセキュリティを保持し、エコシステムの強固な基盤を提供します。



しかし、wasi-coreを完全に標準化したら、次のような他の問題を解決する必要があります。

• 非同期入出力
  
  
• ファイル監視
  
  
• ファイルロック

これはほんの始まりに過ぎないので、アイデアがあれば参加してください！