Man page of CHIKU_WAIT(2)

システムソフトウェアとポエムの差が激しいので，高山病に注意

論文紹介：Blending Containers and Virtual Machines: A Study of Firecracker and gVisor

論文紹介 コンテナ

概要

  • タイトル：Blending Containers and Virtual Machines: A Study of Firecracker and gVisor
  • 著者：Anjali，Tyler Caraza-Harter，Michael M. Swift
  • 会議：VEE '20: Proceedings of the 16th ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments

https://dl.acm.org/doi/10.1145/3381052.3381315

仮想化系トップカンファレンスのVEEで今年の3月に出た論文です． この論文はLXCと，AWSのFirecracker，GoogleのgVisorのパフォーマンスとLinuxカーネル機能の呼び出し頻度や方法を比較し，評価しています． 今までも，パフォーマンスを比較した論文や発表はいくつか出てきていますが，コードのカバレッジを分析して，Linuxカーネル機能の呼び出し頻度や方法を比較は，他にはないこの論文の特徴だと思います． このブログでは，主にカーネルの呼び出し頻度や方法の部分を紹介していこうと思います．

3つの隔離環境(LXC，Firecracker，gVisor)の評価

これら隔離環境の主な違いは，OSの機能がどこにあるかということです．LXCはホストOSカーネルを使い，FirecrackerはゲストOSのカーネル，gVisorはユーザ空間カーネルと呼ばれるものを使います．

この論文では，これらの違いによるLinuxカーネルのコードが実行される頻度や方法を調べるために，lcovというカバレッジテストツールを使って測定しています．測定の結果，実行されたLinuxカーネルコードの行数と割合で見ると，LXCやホストの環境より，FirecrackerやgVisorのほうが多くのLinuxカーネルのコードを実行していたという結果が示されました． CPU，ネットワーク，メモリ，ファイル毎に結果の詳細を書いていきます．

CPUに関連するコードカバレッジの分析

この論文では，sysbenchベンチマークを実行して分析しています． 結果として35kLOCが3つの環境で共有され，gViosrは78k LOC，Firecrakcerが49k LOCが実行されました． また，gVisorはユーザ空間カーネルのSentryでシステムコールを再実装しているにもかかわらず，LXCより多くのホストLinuxカーネルのコードを実行していました．

/archディレクトリでは，FirecrackerとgVisorのフットプリントが大きく，これはKVMを使用しているからだそうです． KVMをFirecrackerはマイクロVMのために，gVisorはSentryへリダイレクトをするために使用しています． また，FirecrackerはgVisorより2550行多いコードを実行しており，これはエミュレーション用のコードでした．

ネットワークに関連するコードカバレッジの分析

この論文では，iperf3ベンチマークを実行して分析しています． 結果，Sentry内にプロトコルスタックを持っているにもかかわらず，gVisorが全体的なカバレッジが高いというものになっっていました． /net/bridgeと/net/coreディレクトリで，gVisorはLXCと同じコードを多く実行しています． これは，LXCとgVisorが同じネットワークインターフェース(ブリッジ）を持っていることが理由っぽいです．

Firecrackerは，ネットワークに関連するカバレッジが低いという結果が示されています． これは，ネットワークに関連する処理の殆どがゲストOSでおこなわれていることが反映されているらしいです．

また，この論文では3つの隔離環境とホスト環境のコールのスタックを比較した結果も述べられています． ホストとLXCのコールスタックを比較した結果，LXCのほうがスタックが大きいという結果が示されています． これは，ブリッジによるネットワークインターフェースの横断コストが挙げられるそうです． gVisorも同様に，ホストより大きいコールスタックが示されています． Firecrackerについては，ホストに似たコールスタックが示されています．

メモリに関連するコードカバレッジの分析

gVisorは，アプリケーションからSentry，Sentryからホストへの2段階の仮想ページマッピングをして，16MB毎のチャンクでメモリ要求することで，LXCでは100万回以上呼び出されるdo_mmap()の呼び出し回数を，5000回程度まで削減しています．

しかしこの論文では，メモリ要求に関してはLXCとほぼ同じコード行が実行されていたことが示されています． また，Firecrackerは最もカバレッジが低く，これはマイクロVMの実行時の最初の初期化の後，ホストに対してmmap()呼び出しは行わないことが理由と書かれています．

ファイルに関するコードカバレッジの分析

この論文では，ext4を用いてファイルのオープン，読み取り，書き込みの3つで分析しています． ファイルシステムの実装が含まれている/fsでは，約18k LOCがgVisorとLXCが共通で実行されており，そのうち約半分の行をFirecrakerによって実行されたという結果が示されています．

また，gVisorとLXCはext4上でoverlayFS使用しており，ext4とoverlayFSフットプリントが増加しています． OverlayFSは，基盤となるFSのメタデータを大量に使用するため，ext4コードが実行される量も増えているそうです．

まとめ・感想

gVisorとFirecrackerはホストカーネルから多くのOS機能を分離して使用しているけれども，ホストのネイティブLinuxより多くのカーネルコードを実行されていることが示されました．

gVisorは，実行できるシステムコールに制限を加えていたり，Sentryでプロトコルスタックを再実装していたので，個人的には以外な結果で面白かったです． コードの全行が同じようにエクスプロイトに対して脆弱であるとは限りませんが，潜在的なリスクはどうなるんだろうかなーなんて思いました．（分析した結果は示されたけど，だからなんだって所があまり書いて無くて気になる...）