Libseccomp: RFE：v2.4.0以降、seccomp_rule_addが非常に遅くなりました

こんにちは@varqox。

はい、syscallリゾルバー関数はいくつかの改善を使用する可能性があります。実際、コードを見ると、次のようないくつかのコメントが表示されます。

/* XXX - plenty of room for future improvement here */

そのコードの改善を検討したい場合は、ヘルプを使用する必要があります。

@pcmooreが述べたように、libseccompを使用してseccompフィルターの_作成_を高速化するための十分な機会があります。 上記の調査では、改善を使用できるいくつかの領域の1つについて概説しました。 これは私のユーザーにとっては問題ではなかったので、私はそれに焦点を合わせていません。

_runtime_のパフォーマンスに関して、私は現在、foo.cで提供したような大きなフィルターにバイナリツリーを使用することに取り組んでいます。 社内のお客様との最初の結果は有望に見えますが、変化にもう一度目を向けたいと思います。 プルリクエストhttps://github.com/seccomp/libseccomp/pull/152を参照してください

OK、システムコールの解決は改善される可能性があると思いますが、それは問題の根本的な原因ではありません。 これは、私が見ているように、db_col_transaction_start（）でのスナップショットの作成です。 arch_filter_rule_add（）が呼び出されますが、これは元のルールで解決されたsyscallを解決するために低速です。

私はそれを次のように見ています：現在のフィルターのセット全体（別名struct db_filter）をすべてのルールで複製したいので、既存のフィルターを利用するのではなく、すべてのフィルターを最初から_構築_し、すべてのフィルターを_コピー_します。 ゼロから構築する必要はありません。コピーが必要なフィルターを完全に構築できます。 何かを見逃したかもしれませんが、db_col_transaction_start（）関数に多くの改善が行われているようです。

内部libseccompdbコレクションにすべての状態があるため、それを複製するのは簡単な作業ではありません。元のルールからコレクションを再生成する方がはるかに簡単です（コードの観点から）。 元のルールを追跡することで、既存のルールを「削除」する機能も提供できます（将来の機能の可能性）。

これは、トランザクションコードを改善できなかったと言っているのではなく、間違いなく改善できますが、現在のコードは、主に単純さという理由から、現在のコードと同じです。

この変更により、ユーザーからのタイムアウトが発生しています。 それは本当に物事を桁違いに遅くしました。

別の考えとして、おそらくこれを変更して、ツリー全体ではなく、トランザクションの開始時にのみルールを複製し、失敗したトランザクションでのみツリーを再作成することができます。 それは完璧ではありませんが、それはかなりの時間を取り戻すはずです。

コンテナとexecプロセスの開始時間が大幅に低下し、ユーザーが2.3倍に固定されるため、何かを行う必要があります。

問題の_ "巨大な" _性質についてこれ以上コメントするつもりはありません。その視点はすでに何度も作成されており、相対的なものとユースケースに依存するものの両方であると考えています。 ただし、v2.4より前のlibseccompリリースは、公開されている潜在的な脆弱性に対して脆弱であることをすべての人に思い出させたいと思いました（問題＃139）。

この問題を懸念している人のために、現在、v2.5リリースのマークが付けられています。

リファクタリングを行ったところ、マイナーリリースでパフォーマンスに「大きな」影響があり、ユースケースに依存していると言ってこれを吹き飛ばしても役に立ちません。 ディストリビューションが2.4に更新されると人々が気づき始めるので、これを真剣に受け止めてください

@crosbymichael変更は単なるリファクタリングではなく、問題を修正し、カーネルの変更をサポートする必要がありました（特に、32ビットx86のソケットシステムコールなど、多重化と直接呼び出しの両方のシステムコールをサポートする必要があります）。

私はこれを吹き飛ばしていません。私はこの問題を解決する方法を考え続けており（上記のコメントを参照）、これを次のマイナーリリースの何かとしてマークしたという事実。 この時点で、あなたのコメントを炎症的であると認識しないようにするのは難しいです。それがあなたの意図でない場合は、将来コメントするときにもっと注意を払うことをお勧めします。 この問題の進捗状況に不満がある場合は、レビューのためにパッチ/ PRを送信していつでもサポートできます。

自分自身とこれを解決しようと考えている他の人に注意してください...

私は最近、トランザクションに関して私たちが行うことを行う理由を思い出しました（すべてを前もってコピーします）。 これを行うのは、失敗せずにトランザクションをロールバックできる必要があるためです。 どうして？
通常のseccomp_rule_add（）操作では、障害が発生した場合でもフィルターをそのまま維持する必要があります。 通常のルール追加の一部としてマルチパートトランザクション（たとえば、x86 / s390 / s390xなどのsocket / ipc syscalls）に失敗した場合、トランザクションの開始時に必ずフィルターに戻れる必要があります（メモリの負荷などに関係なく）。

ルールなしでツリーを複製することは、ツリーの性質とツリー内のリンクのために引き続き困難ですが、内部トランザクションを作成する必要がある場合はいつ選択できるかを選択でき、多くの場合はスキップできます。不要な場合。

私はこれを調べるのにもう少し時間を費やしましたが、ルールの追加中に決定木を破壊的に変更する方法のため、トランザクションでルールの追加をラップすることを回避できるかどうかはわかりません。 つまり、トランザクションの使用を内部で制限する方法を見つける代わりに、トランザクションを高速化する方法を見つける必要があります。ありがたいことに、解決策を見つけたと思います。シャドウツリーです。

現在、新しいトランザクションを作成するたびに新しいツリーを構築し、成功すると破棄します。これまで見てきたように、一部のユースケースでは非常に遅くなる可能性があります。 私の考えでは、コミット時に重複ツリーを破棄する代わりに、重複ツリーに追加したばかりのルールを追加して（現在のフィルターのコピーにする）、次の処理を高速化するために「シャドウトランザクション」として保持しようとします。トランザクションスナップショット。 いくつかのメモ：

• db_col_transaction_start()は、シャドウトランザクションが存在する場合はそれを使用しようとしますが、存在しない場合は現在の動作にフォールバックする必要があります。
• db_col_transaction_abort()は、現在と同じように動作するはずです。 これは、失敗したトランザクションはシャドウトランザクションをクリアしますが（フィルターを復元するにはツリー化する必要があります）、次に成功したトランザクションはシャドウを復元することを意味します。 失敗したトランザクションは、これが大きな問題にならないように十分な頻度である必要があります。
• arch / ABI ops？などの他の操作でシャドウトランザクションをクリアする必要があるかもしれませんが、それはチェックアウトする必要があるものです。 とにかく、シャドウトランザクションをクリアするのは簡単なはずです。
• これには、ルールの追加を高速化するだけでなく、一般的にトランザクションを高速化するという利点があります。 これは今は重要ではないかもしれませんが、トランザクション機能をユーザーに公開するときに役立ちます（これは、BSDの「誓約」のようなメカニズムを実行したい場合に必要になります）。

今夜の夕食後しばらく時間があったので、上記のシャドウトランザクションのアイデアを実装するための簡単なパスを作成しました。 コードはまだ粗雑であり、私のテスト（以下）はさらに粗雑ですが、このアプローチでパフォーマンスが向上しているようです。

• ベースラインテストのオーバーヘッド

# time for i in {0..20000}; do /bin/true; done
real    0m10.479s
user    0m7.641s
sys     0m3.924s

• 現在のマスターブランチ

# time for i in {0..20000}; do ./42-sim-adv_chains > /dev/null; done

real    0m16.303s
user    0m12.584s
sys     0m4.501s

• パッチを適用

time for i in {0..20000}; do ./42-sim-adv_chains > /dev/null; done

real    0m15.021s
user    0m11.540s
sys     0m4.387s

テストのオーバーヘッドを差し引くと、この「テスト」でパフォーマンスが約20％向上することがわかりますが、複雑なフィルターセットのメリットはこれよりも優れている（はるかに優れている？）と思います。

@varqoxおよび/または@crosbymichaelパッチを少しクリーンアップして、PRを作成したら、ご使用の環境でこれをテストできますか？

私のサンプルテストケースはすでにここにあります：

こんにちは、
この問題は、v2.3.3とv2.4.0の間のコミットce3dda9によって発生しました。 次の例を考えてみましょう： foo.c.zip 。
非常に多くのルールが追加されます。 そして、上記のコミット後、約100倍遅く動作します。

v2.4.1を使用したfoo.c実行時間： 0.448
v2.3.3を使用したfoo.c実行時間： 0.077

しかし、PRの準備ができたらすぐに、自分の環境でテストできます。

こんにちは@varqox 、はい、元のレポートにテストケースが含まれているのを見ましたが、実際の使用でどのように機能するかを聞きたいと思っています。 PR＃180を試して、報告していただければ幸いです。ありがとうございます。

こんにちは@pcmoore 、

このPRをしてくれてありがとう。
私はあなたのPR＃180を作成してテストしましたが、その結果は私のテストケースにとって有望です。 顧客がdockerヘルスチェックを使用し、 libseccomp 2.4.xのパフォーマンスの問題に悩まされていたため、この問題を監視しています。
私のテストケースでは、このPRのパフォーマンスはlibseccomp 2.3.3に匹敵します。 詳細は以下の通りです。

環境

MacBookPro上のUbuntu19.04 VM（2 CPU、2Gメモリ）（15インチ、2015年半ば）
カーネル5.0.0-32-ジェネリック
Docker CE 19.03.2

テストケース：

20個のコンテナを準備します。

for i in $(seq 1 20)
do
  docker run -d --name bb$i busybox sleep 3d
done

すべてのコンテナで同時にdocker execを起動してテストを実行します

for i in $(seq 1 20)
do 
  /usr/bin/time -f "%E real" docker exec bb$i true & 
done

結果

libseccomp 2.3.3

0:01.05 real
0:01.12 real
0:01.16 real
0:01.20 real
0:01.23 real
0:01.27 real
0:01.31 real
0:01.35 real
0:01.37 real
0:01.38 real
0:01.40 real
0:01.41 real
0:01.40 real
0:01.40 real
0:01.45 real
0:01.46 real
0:01.47 real
0:01.48 real
0:01.48 real
0:01.49 real

libseccomp 2.4.1

0:00.98 real
0:01.63 real
0:01.67 real
0:01.95 real
0:02.55 real
0:02.70 real
0:02.70 real
0:02.96 real
0:03.04 real
0:03.16 real
0:03.17 real
0:03.21 real
0:03.23 real
0:03.27 real
0:03.24 real
0:03.29 real
0:03.27 real
0:03.29 real
0:03.28 real
0:03.27 real

あなたのPRビルド

0:00.95 real
0:01.12 real
0:01.20 real
0:01.23 real
0:01.28 real
0:01.29 real
0:01.31 real
0:01.37 real
0:01.38 real
0:01.40 real
0:01.43 real
0:01.43 real
0:01.44 real
0:01.45 real
0:01.42 real
0:01.47 real
0:01.48 real
0:01.48 real
0:01.48 real
0:01.50 real

その他のメモ

• このPRを作成する前に、 configure.ac 2.4.1をAC_INITに設定しました。
• このカスタムビルドは/usr/local/libにインストールされています。テスト中にカスタムビルドが使用されていることを確認するために、 ldd /usr/bin/runcを実行して検証しました。
• テストを数回実行しましたが、結果に非常に小さな差異があります。 ですから、それらは偶然の結果ではないと確信しています。

それは素晴らしいです、助けてくれてありがとう@xinfengliu！

こんにちは@pcmoore 、
このPRをありがとう。
私の場合、libseccompのパフォーマンスをv2.3.3と同等のレベルに復元します。

結果

foo.c

g++ foo.c -lseccomp -o foo -O3
for ((i=0; i<10; ++i)); do time ./foo; done 

libseccomp 2.3.3

./foo  0.01s user 0.00s system 98% cpu 0.018 total
./foo  0.02s user 0.00s system 98% cpu 0.020 total
./foo  0.02s user 0.00s system 98% cpu 0.019 total
./foo  0.02s user 0.00s system 98% cpu 0.018 total
./foo  0.02s user 0.00s system 98% cpu 0.019 total
./foo  0.02s user 0.00s system 98% cpu 0.019 total
./foo  0.02s user 0.00s system 98% cpu 0.019 total
./foo  0.02s user 0.00s system 98% cpu 0.019 total
./foo  0.02s user 0.00s system 98% cpu 0.018 total
./foo  0.02s user 0.00s system 98% cpu 0.019 total

平均： 0.0188 s

libseccomp 2.4.2

./foo  0.19s user 0.00s system 99% cpu 0.195 total
./foo  0.19s user 0.00s system 99% cpu 0.194 total
./foo  0.19s user 0.00s system 99% cpu 0.193 total
./foo  0.19s user 0.00s system 99% cpu 0.196 total
./foo  0.19s user 0.00s system 99% cpu 0.195 total
./foo  0.20s user 0.00s system 99% cpu 0.196 total
./foo  0.19s user 0.00s system 99% cpu 0.194 total
./foo  0.20s user 0.00s system 99% cpu 0.197 total
./foo  0.19s user 0.00s system 99% cpu 0.195 total
./foo  0.19s user 0.00s system 99% cpu 0.194 total

平均： 0.1949 s

PR＃180

./foo  0.01s user 0.01s system 98% cpu 0.012 total
./foo  0.01s user 0.00s system 97% cpu 0.013 total
./foo  0.01s user 0.00s system 96% cpu 0.013 total
./foo  0.01s user 0.01s system 97% cpu 0.014 total
./foo  0.01s user 0.00s system 97% cpu 0.012 total
./foo  0.01s user 0.00s system 98% cpu 0.013 total
./foo  0.01s user 0.00s system 98% cpu 0.012 total
./foo  0.01s user 0.00s system 98% cpu 0.013 total
./foo  0.01s user 0.00s system 97% cpu 0.013 total
./foo  0.01s user 0.00s system 97% cpu 0.011 total

平均： 0.0126 s

このPRは、この合成テストでv2.3.3よりもいくらか高速化されているようです。

サンドボックスでの（seccomp_init（）からseccomp_load（）への）フィルターの構築とロード、およびサンドボックス初期化のオーバーヘッド

libseccomp 2.3.3

Measured: 0.0052 s
Measured: 0.0040 s
Measured: 0.0046 s
Measured: 0.0042 s
Measured: 0.0038 s
Measured: 0.0038 s
Measured: 0.0039 s
Measured: 0.0036 s
Measured: 0.0042 s
Measured: 0.0044 s
Measured: 0.0036 s
Measured: 0.0037 s
Measured: 0.0044 s
Measured: 0.0035 s
Measured: 0.0035 s
Measured: 0.0035 s
Measured: 0.0040 s
Measured: 0.0037 s
Measured: 0.0043 s
Measured: 0.0042 s
Measured: 0.0035 s
Measured: 0.0034 s
Measured: 0.0038 s
Measured: 0.0035 s
Measured: 0.0035 s
Measured: 0.0037 s
Measured: 0.0038 s

平均： 0.0039 s

libseccomp 2.4.2

Measured: 0.0496 s
Measured: 0.0480 s
Measured: 0.0474 s
Measured: 0.0475 s
Measured: 0.0479 s
Measured: 0.0479 s
Measured: 0.0492 s
Measured: 0.0485 s
Measured: 0.0491 s
Measured: 0.0490 s
Measured: 0.0484 s
Measured: 0.0483 s
Measured: 0.0480 s
Measured: 0.0482 s
Measured: 0.0474 s
Measured: 0.0483 s
Measured: 0.0507 s
Measured: 0.0472 s
Measured: 0.0482 s
Measured: 0.0471 s
Measured: 0.0498 s
Measured: 0.0489 s
Measured: 0.0474 s
Measured: 0.0494 s
Measured: 0.0483 s
Measured: 0.0498 s
Measured: 0.0492 s

平均： 0.0466 s

PR＃180

Measured: 0.0058 s
Measured: 0.0059 s
Measured: 0.0054 s
Measured: 0.0046 s
Measured: 0.0059 s
Measured: 0.0048 s
Measured: 0.0045 s
Measured: 0.0051 s
Measured: 0.0052 s
Measured: 0.0053 s
Measured: 0.0048 s
Measured: 0.0048 s
Measured: 0.0045 s
Measured: 0.0044 s
Measured: 0.0044 s
Measured: 0.0059 s
Measured: 0.0044 s
Measured: 0.0046 s
Measured: 0.0046 s
Measured: 0.0044 s
Measured: 0.0044 s
Measured: 0.0062 s
Measured: 0.0047 s
Measured: 0.0044 s
Measured: 0.0044 s
Measured: 0.0044 s
Measured: 0.0044 s

平均： 0.0049 s

合成テストではPRはv2.3.3よりも良い時間を与えますが、実際の世界では少し遅くなります（おそらく、より複雑なルールと2つの大きなフィルターをマージするためのseccomp_merge（）の実行が原因です）。 ただし、それでもv2.4.2の約10倍のスピードアップが得られます。

パフォーマンスを確認していただきありがとうございます@varqox！ @drakenclimberが最後のコメントに応答するとすぐに（そして彼が提起する可能性のある残りの問題を修正します）、これをマージします。

ああ、気にしないでください、 @ drakenclimberがPRを承認済みとしてマークしたことに気づきました。 先に進んで、それをマージします。

PR＃180をマージしたばかりなので、パフォーマンスの問題が残っていることに気付いた場合は、コメントしたり、再度開いたりして、これをクローズとしてマークできると思います。 皆さんの忍耐と助けに感謝します！

@pcmooreこれらの変更をすぐにリリースする予定ですか？

これは現在、libseccomp v2.5リリースマイルストーンの一部です。以下のリンクを使用して、v2.5リリースに向けた進捗状況を追跡できます。

• https://github.com/seccomp/libseccomp/milestone/4