タグ: WebAssembly

前の2つの投稿は脅威モデルとseccompサンドボックスについてだった。この投稿はさらに進む：セキュリティプロパティがOSレベルフィルターではなくコンパイルターゲットから来るWebAssembly実行環境について。

なぜWASMセキュリティが違うのか

seccompでは62項目のブロックリストを書いた。新しい危険なシステムコールが現れたら（io_uring、お前を見ているぞ）、リストに追加する。セキュリティモデルは「悪いものをブロックする」だ。

先週sandbox_execを出荷した——AWS Lambdaで学生コードを分離するためにseccomp-bpfを使用する224行のCプログラム。その時の正直な答えは：「WASMの方がクリーンだが、Pythonエコシステムがまだそこにない。」

今週は「Pythonエコシステムがまだそこにない」がミリ秒で何を意味するか正確に測定した。答えは予想以上にニュアンスがある。

先週sandbox_execをリリースした——seccomp-bpfを使ってAWS Lambda内の学生コードを分離する224行のCプログラムだ。当時の正直な答えは「WASMの方がクリーンだが、Pythonエコシステムがまだ追いついていない」だった。

今週は「Pythonエコシステムがまだ追いついていない」がミリ秒単位でどのくらいのコストかを正確に計測した。答えは予想より微妙だった。

今日、私の修士プロジェクトが正式に始動した。前提は単純に聞こえる：AWS Lambda内で学生のコードを安全に実行する。制約がそれを興味深くする。

Lambda Feedbackは学生がコードを提出してリアルタイムで評価される基盤だ。バックエンドはサーバーレス関数を使用する——AWS Lambdaがコンテナを起動し、コードを実行し、結果を返す。

パフォーマンスのため、Lambdaはコンテナを_再利用_する。5分前に学生Aの提出を処理した関数が学生Bの次の処理をするかもしれない。同じファイルシステム、同じプロセスメモリ、同じ/tmp。