WebAssemblyのWeb以外のことぜんぶ話す

2021/03/20 Kernel/VM探検隊online part2 (https://kernelvm.connpass.com/event/201059/) の @nullpo_head (https://twitter.com/nullpo_head) の発表資料です。

Webの外、システムレイヤでのWebAssemblyの応用について、kernel/vm的wasm入門としての話をしたときの資料です。wasmがweb外でなぜアツいのかを、「wasmは Javaが目指したもの + .Net CLIが目指したもの + NaCl/Java Applet/eBPFが目指したもの + Luaの立ち位置を包括的にやろうとしている」という観点から話したやつです。

Logmi様による文字起こし記事がありますhttps://logmi.jp/tech/articles/324956

Transcript

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が適用可能 • カーネル内の実行可能ファイル • イーテリアム • 一般のプラグイン機構 • みなさんもこれ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まわりの人たちが中心のコミュニティ 主導でメンテされている
29. WASI的なモチベーションの応用 WASIのモチベーション(Safe & Portable)も一般化できる • Krustlet • Wasm OCI Image • Wasm • FaaS • みなさんもユースケースを（略 • 特定の言語ランタイムしか受け付けないインフラ • Seccompやcgroupで実行ファイルをガチガチに固める状況
30. Web外Wasmのエコシステム
31. Ecosystem 今回はつぎの二つについてさらっと紹介. 名前だけでも覚えて帰ってください • Runtime • ToolChain
32. 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 • 言わずと知れたやつ. みなさんが思ってるよりは組み込みやすい ほかにもいっぱいあるはず
33. Toolchain 多くの言語が言語ネイティブのツールチェインが バックエンドとしてwasmをサポート（そうでないものもある • 現状webassembly.orgにリストされている言語 • C/C++ • Rust • C# • F# • Go • Kotlin • Swift • D • Pascal • Zig
34. 新しい低レイヤ Wasmはまだまだエコシステムが未熟なので、 整備中ものがたくさんある • Dynamic link • Dwarf / Debugger • Inter-Language Type Procedure 今の時代に低レイヤの仕様が スクラッチから開発されるのを見るのは楽しい
35. Summary • Wasmは複合的なアツさをもつ + Javaが目指したもの (Portable/Platform-Independent) + CLIが目指したもの (Language-Independent) + NaClが目指したもの/eBPF (Safe) + Lua (Open) • 特にOpenさが多様な応用先を生む • 例えば以下のようなspecがある • WASI • Proxy-wasm • これから色々な分野で応用されていくはず • あなたも君だけのWasm Embedding Interfaceを考えよう