SWoPP22022 7/27 OS-3
Accelerating TCP/IP Communicationsin Rootless Containers by Socket SwitchingSWoPP2022 7/27 OS-3松本 直樹(京都大学), 須田 瑛大(NTTソフトウェアイノベーションセンタ)SWoPP2022 7/27 OS-3 12022/7/27
View Slide
本研究の背景コンテナランタイム自体の脆弱性→ランタイムを介した不正操作“Rootless Container”• ランタイム自体をroot権限(特権)なしで動かすことでセキュリティリスクを軽減• ネットワークはモジュール(slirp4netns, RootlessKit)により非特権化→ 性能(スループット)が低いという問題SWoPP2022 7/27 OS-32ホストコンテナブリッジ等vethデバイス要特権！※veth: ペアで構成される仮想的なL2インタフェース2022/7/27
本研究の提案Rootless Container における通信性能を改善するbypass4netnsを提案• コンテナ内のソケットをホスト上のソケットに差し替え(Socket Switching)• 通信がボトルネックとなるモジュールを経由しないことで改善SWoPP2022 7/27 OS-3 32022/7/27
本研究の成果bypass4netns により、スループットが向上することを確認• 特に、外部への通信については顕著な改善がみられるSWoPP2022 7/27 OS-3 438.6 39.20.45235.841.4 39.801020304050Container → Host Host → ContainerThroughput(Gbps)Rootful Rootless w/o bypass4netns Rootless w/ bypass4netns2022/7/27
Rootless Container についてコンテナランタイム自体に脆弱性がある場合がある• Docker CVE-2014-9357悪意のあるコンテナが任意のバイナリを特権で実行可能• runc CVE-2016-3697悪意のあるコンテナが意図しないUIDで動作可能→ ランタイム自体の脆弱性により、特権で不正な操作が可能になる可能性ランタイム自体を非特権で動かす→ Rootless Container• ランタイム自体が一般ユーザー権限で動作する• 脆弱性があった場合、被害範囲を小さくできるSWoPP2022 7/27 OS-3 52022/7/27
Rootless Container におけるネットワーク処理UserNS(UserNamespaces) を用いて、非特権化を実現※UserNS: NS内の特権ユーザーをNS外の一般ユーザーにマップする• ランタイムのおおよその機能は UserNS でカバーネットワークに関して、vethデバイスはホスト側の特権を要する→ veth を利用しない手法でネットワークの非特権化を実現• slirp4netns: コンテナ内→外部の通信を担当• RootlessKit port driver: 外部→コンテナ内の通信を担当SWoPP2022 7/27 OS-3 62022/7/27
Rootless Container におけるネットワーク処理slirp4netns: コンテナ内からホスト外部への通信を中継• コンテナネットワークを扱う 内部 NetNS に TAPデバイスを作成• TAPデバイスを利用して、内部 NetNS から外部への通信を中継SWoPP2022 7/27 OS-3 7ホストslirp4netns内部 NetNSコンテナコンテナブリッジTAP デバイスを作成し、TAP のファイルディスクリプタをホスト側の slirp4netns に渡すTAP デバイスから受け取ったパケットを取得し送信TAPパケットvethveth2022/7/27
Rootless Container におけるネットワーク処理の問題点Rootless Container のネットワークの問題点• 性能の劣化(slirp4netns で顕著)SWoPP2022 7/27 OS-3 838.6 39.20.45235.8051015202530354045Container → Host Host → ContainerThroughput(Gbps)Rootful Rootless w/o bypass4netns2022/7/27
2022/7/27Rootless Container におけるネットワーク処理の問題点性能劣化の原因TCPパケットを再構築し、ソケットから送信するオーバーヘッドSWoPP2022 7/27 OS-3 9パケットAパケットαパケット1パケットBパケット2パケットβdstIP: 192.168.1.1, dstPort: 443dstIP: 151.101.66.132, dstPort: 443dstIP: 133.3.250.189, dstPort: 443slirp4netnsソケットソケットソケット192.168.1.1:443 に connectslirpTCPパケットを再構築し、ペイロードを取得するTAP fd151.101.66.132:443 に connect133.3.250.189 :443 に connect
本研究における提案手法コンテナ内のソケットをホスト上のソケットへ差し替える(Socket Switching)• 外部へ/外部からの通信が対象(コンテナ間の通信はvethで行われるため対象外)• Socket Switching には Seccomp を利用→ コンテナランタイムに対する大きな改変なく実現可能102022/7/27
Seccomp についてSeccomp(Secure computing mode)プロセスで呼び出される syscall を制御するモジュール2種類の制御方式が存在する• 静的なプロファイルに基づく制御• Docker 等で用いられる手法• syscall ごとに挙動をプロファイルとして事前に指定しておく• syscall 呼び出し毎に動的に判断する制御• Seccomp User-space Notification(Seccomp Notify)• bypass4netns で利用SWoPP2022 7/27 OS-3 112022/7/27
Seccomp Notify についてSeccompにおいて動的にsyscallを制御する• 監視プロセスで実行される syscall の読み取りや実行判断を行うSWoPP2022 7/27 OS-3 122022/7/27
Seccomp による Socket SwitchingSeccomp Notify を利用した Socket Switching• SECCOMP_IOCTL_NOTIF_ADDFD を利用SWoPP2022 7/27 OS-3 132022/7/27
bypass4netns での挙動Seccomp Notify を利用し接続先に応じて Socket Switching• コンテナ内のソケットと同じ設定のソケットをホスト上に作成する必要SWoPP2022 7/27 OS-3 14socketsetsockoptconnectsocketsetsockoptbypass4netnssendソケットの作成設定の反映SocketSwitching設定を記録コンテナ ホストSeccomp Notify2022/7/27
Socket Switching の流れbypass4netns では以下の手順に従い Socket Switching を行うソケットに関係がある syscall をSeccomp Notify fd 経由でハンドル1. syscall の引数を読み出す2. syscall が接続先を指定しているa. 接続先が外部のエンドポイント → Socket Switching を行うb. 接続先が外部のエンドポイントでない → 何もしない3. syscall がポートをバインドしているa. ポートが公開対象のポート → Socket Switching を行うb. ポートが公開対象のポートでない → 何もしない4. syscall がソケットの設定を行っている → 設定を記録SWoPP2022 7/27 OS-3 15slirp4netnsを代替RootlessKit port driverを代替2022/7/27
既存アプリケーションにおけるソケット syscall の調査Socket Switching に必要な情報1. ソケットに関係する syscall2. 接続先/元が外部であると分かる syscall3. Socket Switching 前にソケットに対して実行される syscallトレーサーを用いてアプリケーションが利用する syscall を調査• socket(2) で作成された fd に対して実行される syscall を調査SWoPP2022 7/27 OS-3 16socket bind listen acceptclonerecv sendaccept acceptPID=xPID=yfd=α fd=β2022/7/27
調査結果以下のアプリケーションを対象に調査• ping, wget, apache, nginx, iperf3• 対象となるソケットは SOCK_STREAM, SOCK_DGRAM• トレースのログを解析し、対象の syscall を抽出接続先/元が外部であると分かる syscall• connect, sendto(アドレス付き),bindSocket Switching 前にソケットに対して実行される syscall• ソケット作成後から接続先/元が外部であると分かるまでに実行されるsyscall を抽出• 設定を行うsyscall: setsockopt, ioctlSWoPP2022 7/27 OS-3 172022/7/27
bypass4netns での挙動Seccomp Notify で 以下の syscall をフックconnect, sendto, bind, setsockopt, ioctl以下の手順で処理を行う1. Syscall の引数を読み出す2. Syscall が connect, sendto(アドレス付き)であるa. 接続先が外部のエンドポイント → Socket Switching を行うb. 接続先が外部のエンドポイントでない → 何もしない3. Syscall が bind であるa. ポートが公開対象のポート → Socket Switching を行うb. ポートが公開対象のポートでない → 何もしない4. Syscall が setsockopt, ioctl である → 引数を設定として記録SWoPP2022 7/27 OS-3 182022/7/27
bypass4netns での挙動Seccomp Notify を利用し接続先に応じて Socket Switching→ コンテナ内のソケットと同じ設定のソケットをホスト上に作成するSWoPP2022 7/27 OS-3 19socketsetsockoptconnectsocketsetsockoptbypass4netnssendソケットの作成設定の反映SocketSwitching設定を記録コンテナ ホストSeccomp Notify2022/7/27
実装3つのコンポーネントを実装• bypass4netns: Seccomp Notify や Socket Switching の処理を担う• bypass4netnsd: nerdctl と連携し、bypass4netns の管理を担う• nerdctl(改修): bypass4netnsd との連携機能を追加実験的要素として nerdctl v0.17.0 にマージ済み※nerdctl: 高レベルランタイムであるcontainerd用CLI. コンテナ関連の新機能の実験場として開発nerdctl run --label nerdctl/bypass4netns=true alpine で容易に利用可能SWoPP2022 7/27 OS-3 202022/7/27
性能評価及び評価環境以下の観点で性能を評価• スループット• CPU使用率• syscall 実行のオーバーヘッド• アプリケーション(wget, nginx)評価には以下のHyper-V 上の VM 環境を利用• Host CPU: Ryzen 7 PRO 5850U• Host メモリ 32GB• Host OS: Windows 11 Pro (build 22000.739)• VM CPU: 4 コア• VM Memory: 8GB• VM OS: Ubuntu 21.10 (kernel 5.13.0-1025-azure)SWoPP2022 7/27 OS-3 212022/7/27
性能評価(スループット)2つの場合についてスループットを iperf3 で計測Case A. コンテナと接続先/元ホストが同一VMCase B. コンテナと接続先/元ホストが別のVM→ いずれの場合についても、従来より性能が向上したことを確認38.6 39.20.45235.841.4 39.801020304050Container → Host Host → ContainerThroughput(Gbps)Rootful Rootless w/o bypass4netns Rootless w/ bypass4netns16.8 16.01.1113.621.016.10510152025Container → Other host Other host → ContainerThroughput(Gbps)Rootful Rootless w/o bypass4netns Rootless w/ bypass4netns2022/7/27 22A. コンテナと接続先/元ホストが同一VM B. コンテナと接続先/元ホストが別のVM
性能評価(CPU使用率)iperf3(1Gbps制限,120秒間)動作中のCPU使用率(sys + user)を計測→ いずれの場合でも、従来よりCPU使用率が減少したことを確認232022/7/2705101520253035400369121518212427303336394245485154576063666972757881848790939699102105108111114117120CPU使用率(user + sys) %経過時間(秒)w/ bypass4netns(case A) w/o bypass4netns(case A) w/ bypass4netns(case B) w/o bypass4netns(case B)
性能評価(syscall 実行のオーバーヘッド)単純なプログラムで syscall 実行のオーバーヘッドを計測• socket(SOCK_DGRAM), connect, close を繰り返す• 10万回実行し、平均値で比較→従来より実行に30倍の時間を要することを確認Seccomp Notify では特定の syscall のみ処理するため、実アプリケーションならば影響は小さくなると考えられるSWoPP2022 7/27 OS-3 24w/o bypass4netns w/bypass4netns1回あたりの実行時間(us) 3.22 100.052022/7/27
性能評価(wget)コンテナ内で外部へ wget を実行したときにかかる時間を計測• 環境は B. 別VM で、Nginx をサーバーとして利用→ 小さいファイルは Socket Switching のオーバーヘッドの影響が出ているファイルサイズが一定以上でRootfulな場合と同等の性能SWoPP2022 7/27 OS-3 2501234561KiB 32KiB 128KiB 512KiB 1MiBダウンロード時間(ミリ秒)ファイルサイズRootful Rootless w/o bypass4netns Rootless w/ bypass4netns00.511.522.532MiB 128MiB 512MiB 1GiBダウンロード時間(秒)ファイルサイズRootful Rootless w/o bypass4netns Rootless w/ bypass4netns2022/7/27
性能評価(nginx)コンテナ内の nginx を公開した場合でダウンロード時間を計測• 環境は B. 別VM で、wget をクライアントとして利用→ bypass4netns を用いない場合に比べて用いる場合のほうが高速Rootful なコンテナとほぼ同等の性能SWoPP2022 7/27 OS-3 2601234561KiB 32KiB 128KiB 512KiB 1MiBダウンロード時間(ミリ秒)ファイルサイズRootful Rootless w/o bypass4netns Rootless w/ bypass4netns00.050.10.150.20.250.30.350.40.4532MiB 128MiB 512MiB 1GiBダウンロード時間(秒)ファイルサイズRootful Rootless w/o bypass4netns Rootless w/ bypass4netns2022/7/27
考察1. 他のネットワークコンポーネントとの組み合わせコンテナのNetNSや内部NetNSをバイパスすることによる弊害• 外部エンドポイントへの通信の制御をホスト側でする必要がある(要特権)2. セキュリティ• NetNSによるネットワークの分離を壊している• Seccomp Notify で time-of-check to time-of-use(TOCTOU)攻撃が成立する可能性がある3. slirp4netns, RootlessKit との関係(bypass4netns の制約)• VXLAN をサポートしない→ Usernetes 等では利用できない※ Usernetes: 特権なしで動く Kubernetes• 全ての通信について bypass4netns で高速化できるわけではないSWoPP2022 7/27 OS-3 272022/7/27
まとめ目的: Rootless Container における外部へ/からの通信の高速化• Rootless 化による通信性能の劣化の改善提案: Socket Switching による高速化手法 bypass4netns• コンテナ内のソケットをホスト上のソケットに差し替える実装, 評価: 既存のモジュールに比べて高速化を達成• コンテナ内→外部の通信については 約20倍の高速化を達成考察: セキュリティ上の課題や bypass4netns 自体の制約が存在• 従来のネットワークモジュールと組み合わせた利用が必要SWoPP2022 7/27 OS-3 282022/7/27
補足資料: 性能評価(スループット)-r オプション(server → client に流す)場合についても同様の傾向SWoPP2022 7/27 OS-3 2953.543.04.2526.155.245.20102030405060Container → Host Host → ContainerThroughput(Gbps)Rootful Rootless w/o bypass4netns Rootless w/ bypass4netns13.520.93.5611.813.621.20510152025Container → Host Host → ContainerThroughput(Gbps)Rootful Rootless w/o bypass4netns Rootless w/ bypass4netnsA. コンテナと接続先/元ホストが同一VM B. コンテナと接続先/元ホストが別のVM2022/7/27
補足資料: 性能評価(スループット)bypass4netns を使うとRootful なコンテナより速い場合がある→ iptables や veth, bridge のオーバーヘッドによる可能性curl のパケット処理に関係したカーネル関数数を ipftrace2 で集計Rootful な場合に比べて、bypass4netns の場合は関数数が少ないことを確認→ bypass4netns を利用する場合が速い原因の一つとして考えられるSWoPP2022 7/27 OS-3 30Rootful w/o bypass4netns w/ bypass4netns処理カーネル関数数 673 922 1982022/7/27
補足資料: トレース結果(wget)• DNS 名前解決 → 仮接続 → TCP 接続で取得• connect(2) で差し替えた直後に ioctl(2) や fnctl(2) を実行• ハンドルする必要は特にない• connect(2) 前に実行される場合はありそう?312022/7/27
補足資料: トレース結果(Nginx)• Nginx 特有のイベント多重な処理が行われていることが分かる• 複数プロセスでの epoll_wait による待ち受け• bind(2) → listen(2) → 別プロセスで accept(2)• bind(2) 以降は特にハンドルする必要はない322022/7/27 SWoPP2022 7/27 OS-3
mt2naoki
yukinobaba
muraoka7
ryou0634
shuntaros
temoki
kikuzo
ahspragu
kinakomoti321
.png){kind=avatar}
researchconf
naoto0804
stktu
yoshipon
shpigford
colly
sferik
destraynor
jeffersonlam
productmarketing
maggiecrowley
bkeepers
deanohume
palkan