1.
WebAssemblyの
Web以外のことぜんぶ話す
Takaya Saeki (@nullpo_head)
Kernel/VM勉強会 online part 2

2.
WebAssemblyと
は？(一般的なやつ
ウェブブラウザのクライアントサイドスク
リプトとして動作する低水準言語である。
ブラウザ上でバイナリフォーマットの形で
実行可能であることを特徴とする [Wikipediaより]
応用例色々
- Web: Google Meet, Figma, AutoDesk
- ゲーム

3.
今日はそういう話はしません

4.
今日のFocus：
Web外Wasm
~Kernel/VM的wasm入門~

5.
Web外wasmってやつがあります
• Wasmer
• Wasmをネイティブで動かすランタイム (Emscripten, WASI)
• Envoy
• パケットやHTTPリクエストの許諾や改変をwasmプラグインで書ける
• Krustlet
• Kubernetes上でwasmコンテナを実現する
• Kernel-wasm
• Linuxカーネル内でコンテキストスイッチ無しでWasmバイナリを動かす
• Nabulet
• Wasmでmicrokernelを高速に実現する
=> 一発ギャグではない! アツいフロンティアがある

6.
WasmのWeb以外のこと全部話す
今日全部話すこと
1. Web外Wasmがなぜアツいのか
2. WasmがWebの外でどう使われているか
3. Web外Wasmのエコシステム
今日話さないこと
1. WasmのメインフィールドであるWebについて
2. Wasmの詳細な基本仕様について

7.
何がwasmを
そんなにアツくさせるのか

8.
Wasmがなぜアツいのか
• Wasmが夢見る世界は複合的な側面をもつ
+ Javaが目指したもの (portable executable)
+ CLIが目指したもの (common language bytecode VM)
+ NaClが目指したもの/eBPF (secure/isolated sandbox)
+ Lua (embeddable runtime)
=>WasmのことをJVM againやeBPF againだと理解すると、
ほかの側面のアツさを見逃す

9.
Wasmをアツくする特徴
Fast, safe, and
portable semantics:
• Fast
• Safe
• Well-defined
• Hardware-independent
• Language-independent
• Platform-independent
• Open
Efficient and
portable representation:
• Compact
• Modular
• Efficient
• Streamable
• Parallelizable
• Portable

10.
Wasmをアツくする特徴
• Safe
Untrustedなコードを安全に動かすことができる (like eBPF, NaCl)
• JVMでは厳しい
• Language-Independent
低レベルな言語を含め、言語を選ばない (like NaCl. CLIもやや実現
• JVM/eBPFでは現実的には厳しい
• Portable/Platform-Independent
環境/OSを選ばない (like JVM
• NaClでは厳しい
• Open
ホスト環境とのAPIインターフェースがオープンである (like Lua, NaCl
• 今まで決定的な選択肢が存在しなかった
Design Goalsの13個のGoalsから、注目する4つを抜粋

11.
Wasmがなぜアツいのか（改
• Wasmが目指す世界は複合的な側面をもつ
+ Javaが目指したもの (Portable/Platform-Independent)
+ CLIが目指したもの (Language-Independent)
+ NaClが目指したもの/eBPF (Safe)
+ Lua (Open)
=>WasmのことをJVM againやeBPF againだと理解すると、
ほかの側面のアツさを見逃す
=>しかもそれぞれの需要のための投資が集中するからエコシス
テムの発展が速いのも魅力

12.
4つの特徴から見る言語仕様

13.
Wasmの基礎言語仕様:
1. Language / 2. Platform Independent
• 低レベルなスタックマシンのバイナリバイトコード
• JVMやCLIとは違い、GCもオブジェクトのようなOOPの概念もない
• ハーバードアーキテクチャ
• 基本VMランタイムで動く
• 言語仕様が小さいのでコンパイルも可能
 様々なコンパイラが第1ターゲットとしてサポートできる
(Like: NaCl / Unlike: JVM (Graal含む))
 ホストアーキテクチャに依存しない
(Like: JVM / Unlike: NaCl)

14.
Wasmの基礎言語仕様:
3. Safe
• ホストランタイムから隔離された単一メモリ空間を持つ
• そしてハーバードアーキテクチャである
• デフォルトでは外界に副作用を行えない
• Structuredな言語構造しかない (block, loop…
• ジャンプや条件付ジャンプ、CallなどはBasic Blockにしか飛べない
• ローカル変数の存在
• CallスタックはVMが管理するのでVM上はControl Flow Integrityがある
• VMの上の言語レベルでCFIがあるかどうかは話は別だけど..
• 構造化プログラミング以後のアセンブリ言語だとでも思ってください
 UntrustedなコードをWasm VM上/AOTで動かすことができる
(Like: NaCl, eBPF / Unlike: JVM)
参考資料：カーネル空間ですべてのプロセスを動かすには -TAL, SFI, Wasmとか - カーネル/VM探検隊15 (slideshare.net)

15.
Wasmの基礎言語仕様:
4. Open
Wasmはオブジェクトファイ
ルフォーマットの仕様を含む
• webでもなければアセンブリでも
なければ言語仕様でもない・・・？
• ホストにImport/Exportする
関数/変数etcの定義がある
• しかし、具体的中身については
仕様では定めない(重要)
• 最も一般的なのはJSとのglue
• 似たものはあまりないが、
Luaが活躍しているフィールド
Chapter 2. A look inside WebAssembly modules - WebAssembly in Action:
With examples using C++ and Emscripten (manning.com)
Portable, L.I., Safeな上で、
さらにOpenであることが
Wasmに多様な応用を生む!

16.
Wasm Embedding Interfaces
Wasmはオブジェクトフォーマット.
ELFが実際何をできるかはPOSIX/Linux/BSDが決めるように、
Wasmが何ができるかは外のInterfaceが決める
• Web / JS
• WASI
• Proxy-Wasm
• その他面白インターフェース
• In-kernel
• Ethereum
• TEE
• などなど

17.
だからWasmは既存技術の
リバイバル「ではない」！

18.
Wasmがwebの外で
どう使われてるか
特にWASIとProxy-Wasmついて

19.
WASI
• OSの上でwasm executableを動か
すためのPortableなAPI / ABI
• POSIXと同じか少し下のレイヤ
• Safe/Portableさを利用している
• 有名かつ直感的なEmbedding
Interface
• Bytecode Allianceによってコミュニ
ティベースで仕様がメンテされてる
• Mozilla, Fastly, Intel, Redhat…

20.
WAI APIの例
• FS, processなどのインターフェースを定義
• ここにAPIがドドーンとある:WASI/docs.md at main · WebAssembly/WASI (github.com)
Standardizing WASI: A system interface to run WebAssembly outside the web - Mozilla
Hacks - the Web developer blog

21.
WASI セキュリティ
• 独自のセキュリティ機構をもつ（予定）
• WasmはSafeでIsolated！ …本当?
語弊がある. ホストが提供するAPI (systemcall)の安全性に依存する
• Capability Baseのセキュリティ機構
• 例えばFSのアクセスはディレクトリごとにcapabilityを
取得する必要がある
• 多くのMicrokernelを想起させる機構
• まだまだ策定中
• イメージとしては、スマホアプリのようなセキュリティモデルが
実現できるようになる（かも）
• ネイティブみたいにSeccompでガチガチに固めたりしなくていい
 WASIはPortableな実行ランタイムであり、
しかもセキュリティ的にexecutableとしても先進性がある

22.
Proxy-wasm
WebAssembly for Proxies
• Portable/Safe/Openさを利用
• Envoyがリファレンス実装
• Nginxなども試験実装がある
• L4/L7 リクエスト/レスポンスを
自由にこねくり回すロジックをWasmが
発行するためのEmbedding Interface
• Envoyまわりの人たちが中心のコミュニティ
主導でメンテされている
• Google, Tetrate…

23.
どういうこと？
• パケットやHTTP通信が
来た時に呼ばれる関数をWasm
側からexport
• EnvoyなどのProxyは通信が発生
したさいにその関数を
呼ぶ
• Wasm側はそこでさらに、
Proxy側が定義したAPIを読んで
ログを書きだすなりレスポンス
を返すなりする
 Wasmのランタイムとの
双方向のインターフェースに
よって実現

24.
Proxy-wasmはなぜうれしい？
• Envoyで言えば、同じ仕組みを前からC++ static libraryを
プラグインとして差し込むことで実現できた
• 比較してwasmの利点
• Safe
• Untrustedなコードを実行できる
• Wasm側がクラッシュしてもProxy側に影響がない
• Portable
• アーキテクチャ/CPU非依存に実現できる
• Language Independent
• C++だけでなく、RustやGoでproxy pluginを実装できる
 これはかなり便利な一般化できる話.
現在だとLuaのフィールド

25.
Proxy-wasmのモチベーションの
一般化が教えてくれること
• 一般に、双方向のAPI(hostcall/guestcall)が欲しくて、
Safeでportable, そしてfastに動いてほしい場所にwasmが適用可能
• In-kernel executable
• Ethereum
• 一般のプラグイン機構
• みなさんもこれWasmでもっとうまくやれるんじゃね？というユー
スケースを考えよう！
• 特定の組み込み言語を使っている
• 特定の言語向けにしかAPIがない
• 双方向のAPIを必要とする
• APIを用意してあげたいがIPCのコストは許容できない
• 例えばVimのようなエディタ, ETL..?

26.
プロプライエタリプロダクトの
有名なWasm組み込み事例
CDN
• CDNのエッジでパケット操作のロジックを書くために利用する
• FastlyのLucet
• VCLの流れ
• CloudFlare
• Proxy-wasmとまったく同じモチベーション.
というかFastlyが多分元祖.

27.
Proxy-wasm
WebAssembly for Proxies
• Portable/Safe/Openさを利用
• Envoyがリファレンス実装
• Nginxなども試験実装がある
• L4/L7 リクエスト/レスポンスを
自由にこねくり回すロジックをWasmが
発行するためのEmbedding Interface
• Envoyまわりの人たちが中心のコミュニティ
主導でメンテされている
• Google, Tetrate…

28.
Proxy-wasm
WebAssembly for Proxies
• Portable/Safe/Openさを利用
• Envoyがリファレンス実装
• Nginxなども試験実装がある
• L4/L7 リクエスト/レスポンスを
自由にこねくり回すロジックをWasmが
発行するためのEmbedding Interface
• Envoyまわりの人たちが中心のコミュニティ
主導でメンテされている
• Google, Tetrate…

29.
Proxy-wasm
WebAssembly for Proxies
• Portable/Safe/Openさを利用
• Envoyがリファレンス実装
• Nginxなども試験実装がある
• L4/L7 リクエスト/レスポンスを
自由にこねくり回すロジックをWasmが
発行するためのEmbedding Interface
• Envoyまわりの人たちが中心のコミュニティ
主導でメンテされている
• Google, Tetrate…
Tetrate

30.
宣伝(Tetrate)

31.
WASI的なモチベーションの応用
WASIのモチベーション(Safe & Portable)も一般化できる
• Krustlet
• Wasm OCI Image
• Wasm
• FaaS
• みなさんもユースケースを（略
• 特定の言語ランタイムしか受け付けないインフラ
• Seccompやcgroupで実行ファイルをガチガチに固める状況

32.
Web外Wasmのエコシステム

33.
Ecosystem
今回はつぎの二つについてさらっと紹介.
名前だけでも覚えて帰ってください
• Runtime
• ToolChain

34.
Wasm Runtimes
※ざっと見ただけなので不正確な紹介になっている可能性があります
• Wasmtime
• Bytecode alliance project
• リファレンス実装的側面がある
• JITネイティブコード生成バックエンドはCranelift
• Wasmer
• Wasmer社が開発している
• バックエンドはCranelift, singlepass, LLVM
• Lucet
• Bycode alliance project. Fastly社由来
• CDNで使われている. AOTができる. Wasmtimeと多くのコンポーネントを共有
• WAVM
• LLVMをつかってコードを生成するらしい
• Wasm3
• JITをしない代わりに組み込みやすく、高速なインタプリタ
• V8
• 言わずと知れたやつ. みなさんが思ってるよりは組み込みやすい
ほかにもいっぱいあるはず

35.
Toolchain
多くの言語が言語ネイティブのツールチェインが
バックエンドとしてwasmをサポート（そうでないものもある
• 現状webassembly.orgにリストされている言語
• C/C++
• Rust
• C#
• F#
• Go
• Kotlin
• Swift
• D
• Pascal
• Zig

36.
新しい低レイヤ
Wasmはまだまだエコシステムが未熟なので、
整備中ものがたくさんある
• Dynamic link
• Dwarf / Debugger
• Inter-Language Type Procedure
今の時代に低レイヤの仕様が
スクラッチから開発されるのを見るのは楽しい

37.
Summary
• Wasmは複合的なアツさをもつ
+ Javaが目指したもの (Portable/Platform-Independent)
+ CLIが目指したもの (Language-Independent)
+ NaClが目指したもの/eBPF (Safe)
+ Lua (Open)
• 特にOpenさが多様な応用先を生む
• 例えば以下のようなspecがある
• WASI
• Proxy-wasm
• これから色々な分野で応用されていくはず
• あなたも君だけのWasm Embedding Interfaceを考えよう