Libseccomp: Q：異なるスレッドでSCMP_ACT_NOTIFYを使用して異なるフィルターを使用することはできません

@drakenclimberは、これについて何らかの説明が得られるまで、今後のv2.5.1リリースを保持します。 元のレポートを完全に理解しているかどうかはまだわかりませんが、v2.5.1はseccomp_reset(NULL, ...)概念を実装する最初のリリースであるため、確認できるまで少し待ちましょう...

これをv2.5.1マイルストーンに今のところ単なるブロッカーとして追加すると、調査中に変更される可能性があります。

@drakenclimberは、これについて何らかの説明が得られるまで、今後のv2.5.1リリースを保持します。 元のレポートを完全に理解しているかどうかはまだわかりませんが、v2.5.1はseccomp_reset(NULL, ...)概念を実装する最初のリリースであるため、確認できるまで少し待ちましょう...

同意しました。 しましょう。

libseccompは、通知fdをグローバル変数state.notify_fd格納します。 これにより、異なるスレッドで異なるフィルターを使用するマルチスレッドアプリケーションにlibseccompを使用することができなくなります（つまり、TSYNCを使用しない場合）。

その最後の文についてもう少し詳しく説明していただけますか？ あなたが何を伝えようとしているのか理解できません。

FWIW、seccomp通知FDはプロセスグローバルオブジェクトであり、カーネルから要求できるのは1回だけです。 https://github.com/seccomp/libseccomp/issues/273を読んで、この問題の背景をさらに知ることができます。

libseccompはありseccomp_reset(NULL, ...)グローバル変数をリセットするにはstate.notify_fd 。 しかし、 seccomp_reset()は、 state.nr_seccomp = -1をリセットするという不幸な結果をもたらします。

state.nr_seccomp = -1リセットすることが重要な問題であるのはなぜですか？ nr_seccompフィールドが-1リセットされた場合、次にseccomp(2)を使用できる操作が要求されたときに、ライブラリはseccomp(2)がサポートされているかどうかを確認します。利用可能な場合はそれを使用します。 はい、それはseccomp(2)への余分な呼び出しをもたらす可能性がありますが、それは大きな問題ではないはずです、それはあなたのユースケースの懸念ですか？

@ alban-私からの同様の質問。 私は、賢明なマルチスレッド、マルチseccomp-filterのユースケース（C）を発明しようと少し時間を費やしましたが、実際には何も思いつきませんでした。

os.LockOSThread()のGoドキュメントを読みましたが、それは私には理にかなっています。 しかし、私はこの知識をマルチスレッド、マルチseccomp-filterソリューションに変換するのに苦労しています。

あなたが考えていることのいくつかの擬似コードまたはいくつかの高レベルの設計を共有できますか？ それなら、喜んでCでプロトタイプを作成します。

その最後の文についてもう少し詳しく説明していただけますか？ あなたが何を伝えようとしているのか理解できません。

libseccomp-golangで単体テストに取り組んでいるときに、次のシナリオがテストされていることに気付きました。

1. ユニットテストの最初の実行では、seccompポリシーをせずに適用されたSECCOMP_FILTER_FLAG_TSYNC （これは、スレッドレベルではなく、プロセス・レベルで適用されることを意味する）が、でSECCOMP_FILTER_FLAG_NEW_LISTENER libseccompを格納するように（ state.notify_fdのfd）。
2. 同じユニットテストが同じプロセスで別のスレッドで再度実行されます（Goでruntime.LockOSThreadを使用して確認します）。 ただし、libseccompは、新しいフィルターの新しいfdを取得する代わりに、前のseccompフィルター（ state.notify_fd ）のfdを再利用します。 次に、間違ったseccomp fdでイベントを受信することが予想されるため、テストは失敗します。

FWIW、seccomp通知FDはプロセスグローバルオブジェクトであり、カーネルから要求できるのは1回だけです。 この問題の背景については、＃273をご覧ください。

私が理解したところによると、カーネルは、フィルターツリーで1つのseccomp通知FDのみを取得するように制限しています。 ただし、上記のシナリオでは、同じプロセスの2つのスレッドが異なるフィルターツリーを使用しているため、カーネルの観点からは問題ありません。

SECCOMP_FILTER_FLAG_NEW_LISTENER異なるフィルターツリーを使用するこのシナリオは、意図的に作成されたものではなく、同じプロセスで実行されているlibseccomp-golang単体テストの結果として作成されたものです。 しかし、根本的な原因はスレッド間で共有されるグローバル変数state.notify_fdを使用するlibseccompであるため、ここでこのバグを開いてディスカッションを開く必要があると思いました。 ただし、これが「WONTFIX」として閉じられれば問題ありません（他のlibseccompユーザーがこの種のシナリオをサポートする必要があるかどうかはわかりません）。 その場合、libseccomp-golang単体テストを別の方法で作成できます（つまり、テストの反復ごとに個別のプロセスを使用します）。 とにかくそれを行う必要があります（スレッドレベルのフィルターとプロセスレベルのフィルターの混合を避けるために-カーネルによって拒否されます）。

libseccomp-golangで単体テストに取り組んでいるときに、次のシナリオがテストされていることに気付きました。

1. ユニットテストの最初の実行では、seccompポリシーをせずに適用されたSECCOMP_FILTER_FLAG_TSYNC （これは、スレッドレベルではなく、プロセス・レベルで適用されることを意味する）が、でSECCOMP_FILTER_FLAG_NEW_LISTENER libseccompを格納するように（ state.notify_fdのfd）。
2. 同じユニットテストが同じプロセスで別のスレッドで再度実行されます（Goでruntime.LockOSThreadを使用して確認します）。 ただし、libseccompは、新しいフィルターの新しいfdを取得する代わりに、前のseccompフィルター（ state.notify_fd ）のfdを再利用します。 次に、間違ったseccomp fdでイベントを受信することが予想されるため、テストは失敗します。

ああ、それは今より理にかなっています。 TSYNCをlibseccomp-golangバインディングのデフォルトにするべきかどうか疑問に思うことがよくあります。 Goのスレッドのあいまいさを考えると、はるかに安全な選択のようです。

私が理解したところによると、カーネルは、フィルターツリーで1つのseccomp通知FDのみを取得するように制限しています。 ただし、上記のシナリオでは、同じプロセスの2つのスレッドが異なるフィルターツリーを使用しているため、カーネルの観点からは問題ありません。

SECCOMP_FILTER_FLAG_NEW_LISTENER異なるフィルターツリーを使用するこのシナリオは、意図的に作成されたものではなく、同じプロセスで実行されているlibseccomp-golang単体テストの結果として作成されたものです。 しかし、根本的な原因はスレッド間で共有されるグローバル変数state.notify_fdを使用するlibseccompであるため、ここでこのバグを開いてディスカッションを開く必要があると思いました。 ただし、これが「WONTFIX」として閉じられれば問題ありません（他のlibseccompユーザーがこの種のシナリオをサポートする必要があるかどうかはわかりません）。 その場合、libseccomp-golang単体テストを別の方法で作成できます（つまり、テストの反復ごとに個別のプロセスを使用します）。 とにかくそれを行う必要があります（スレッドレベルのフィルターとプロセスレベルのフィルターの混合を避けるために-カーネルによって拒否されます）。

これについて@drakenclimberの意見を

libseccompでこれを「修正」するには、libseccompスレッドを認識させる必要があります。これには、多くの課題と落とし穴があります。現在、これは悪い考えだと思います。 ただし、議論のために、libseccompスレッドを認識させると、内部グローバル状態をスレッド固有の状態にしたり、場合によってはフィルターツリー固有の状態にすることもできます。 どちらの場合でも、現在のAPI（ seccomp_reset(NULL, ...) ）はまだ妥当だと思うので、APIをそのままにしておくようにしたいと思います。 懸念がある場合は、すぐにお知らせください。

@drakenclimber？ 上記に異議がない限り、v2.5.1リリースに戻ったと思います。

これについて@drakenclimberの意見を

同意します。 @ tych0の元のパッチセットとコメント、およびカーネルコード自体を掘り下げることに時間を費やしました。 彼が想定しているユースケースは、コンテナ化されたプロセスが行き来する間に通知ハンドラを実行する監視プロセスです。 これらのコンテナ化されたプロセスが通知のあるシステムコールを呼び出すと、監視プロセスは追加のロジックを実行して要求を許可/拒否できます。

そうは言っても、私は複数の通知呼び出し元とハンドラーを持つマルチスレッドの単一プロセスのユースケースを考え出そうとしました。 正直なところ、私はそのようなシナリオを首尾一貫して作成することができませんでした。 これはかなり不自然なユースケースであり、現実的なユースケースを理解できないため、このWONTFIXにマークを付ける必要があります。

余談ですが、カーネルに複数の通知fdsをプロセスに返すようにさせることができました。 複数のpthreadを作成し、それらすべてに通知アクションを含むseccompフィルターをすぐにロードさせることで、2つまたは3つの異なる通知fdをユーザースペースプロセスに返すことができる場合がありました。 これは非常に非現実的であるため、このカーネルの問題をWONTFIXとしてマークすることにも傾倒します。

@drakenclimber？ 上記に異議がない限り、v2.5.1リリースに戻ったと思います。

素晴らしい。 来週初めに作業を開始できるはずです。

ここでは全員が同意しているようですので、この問題を解決します。 @alban何か重要なものが不足していると思われる場合は、この問題をお知らせいただくか、再度開いてください。すべて解決できます。

みんな、ありがとう。