Libseccomp: バグ：openmpとの互換性

注：私はまだあなたのテストケースを見ていません、私はあなたのよく書かれた説明に基づいて推測しています

これのマルチスレッドの性質を考慮して、カーネルにフィルターをロードする前に、 SCMP_FLTATR_CTL_TSYNCフィルター属性をtrueに設定してみましたか？

• http://man7.org/linux/man-pages/man3/seccomp_attr_set.3.html

スレッドに分割する前にseccompフィルターを追加したため、 SCMP_FLTATR_CTL_TSYNC設定しませんSCMP_FLTATR_CTL_TSYNCを追加しても、違いはありません（これは、ペダンティックエラー処理で100行未満です）。

さて、私はそれについて言及したかっただけです。 正しく実行しているようです（新しいスレッドを生成する前にフィルターを設定します）。 よく見る必要がありますが、すぐにそれを行う機会がないかもしれません。

私が露骨に間違ったことをしていないという確認は私にとって十分です。 ゆっくりしてください！

シングルスレッドの例./seccomp_omp -t 1 -k 0では、openmpはシングルスレッドのみが実行されることを認識しているため、openmpはマルチスレッドのforループで通常行う同期の多くをバイパスします。 カーネルのseccomp_run_filters（）で処理されたシステムコールを観察することでこれを確認しました。 予想通り、__ NR_write（）の呼び出しと__NR_madvise（）の呼び出しがあり、seccompがカーネルにスレッドを強制終了するように指示しました。

マルチスレッドの例./seccomp_omp -t 2 -k 0では、openmpはforループを並列化しようとします。 したがって、openmpライブラリの多くが利用されます。 これは、seccomp_run_filters（）を介してシステムコールを再度監視するときに明らかになります。 __NR_mmap（）、__ NR_mprotect（）、__ NR_clone（）、__ NR_futex（）、およびその他のsyscallは、madvise（）を呼び出す前に呼び出されます。 最終的に、2つのスレッドのうちの1つが最終的にmadvise（）を呼び出し、seccompがそのスレッドを適切に強制終了します。 しかし、openmpはスレッド間で同期を取り、2番目のスレッドがmadvise（）を呼び出す（そして強制終了する）前に、2番目のスレッドはデッドスレッドからの何かを待機しているときにfutex（）を呼び出します。 そして、これがプログラムがハングする理由です。 1つのスレッドが強制終了され、2番目のスレッドは（デッドスレッドからの）データが到着しないのを待っています。

私は、OpenMPでずっと働いていたが、いくつかの議論[があるように思われていない1 、 2 、 3並列ブロック内の信号で、...]。 最終的には、避けるのが最善の難しい問題のように見えます。

いくつかの潜在的な簡単な解決策があるようです：

1. デフォルトのハンドラーとしてSCMP_ACT_KILLを使用しないでください。 代わりに、代わりにエラーコードを使用するように切り替えます（例： SCMP_ACT_ERROR(5) 。 サンプルプログラムでこの変更を行い、正しく終了することを確認しました。

2. openmpの機能が必要ない場合は、pthread_create（）やfork（）などのより一般的なソリューションの使用に切り替えることもできます。

@drakenclimberなので、問題は実際にはopenmpが追加のシステムコールを作成しているだけのように聞こえますが、通常はフィルターの一部ではない可能性がありますか？ それとも、より大きなポイントが欠けていますか？

@drakenclimberお時間を

より多くのコンテキストを与えるために：私は科学的なコードを書いているので、OpenMPで物事をシンプルに保つのが好きです。 ただし、ユーザーを自分自身から保護したいとも思っています。 したがって、私のプログラムが異常なことをした場合は、それを無効にするだけです。 私が最終的に達成したいのは、プロセス（＃96）をやや妥当なエラーメッセージで強制終了することだと思います。

私はではerrnoに使用する必要がありますどのような値SCMP_ACT_ERROR密接に模倣するためにSECCOMP_RET_KILL_PROCESS ？ すべてのシステムコールで正常に機能するものはありますか？

@ pcmoore-ちょっと。 しかし、より大きな問題は、openmpが並列構造内でシグナルを適切に処理しないことだと思います。 これは仕様によるものだと思います。

@ kloetzl-心配ありません

ctx = seccomp_init(SCMP_ACT_ERRNO(ENOTBLK));
...
bool kill_process = false;
int rc;
#pragma omp parallel for num_threads(THREADS)
  for (int i = 0; i < THREADS * 2; i++) {
    fprintf(stderr, "%u\n", func(i));
    if (i == K) {
      rc = madvise(NULL, 0, 0); 
      if (rc < 0)
        kill_process = true;
      }   
    // sleep(10);
  }

  if (kill_process)
    goto error;

  seccomp_release(ctx);
  return 0;
error:
  seccomp_release(ctx);
  return -1; 
}

errnoがSCMP_ACT_ERRNO()返す必要があるかどうかについては、実際にはあなた次第です。 SCMP_ACT_ERRNO()は、すべてのシステムコールで機能します。 そして、あなたのプログラムがそれを処理し、ユーザーにエラーを返すものになるので、あなたはあなたに最適なerrnoを選ぶことができます。 実際、あいまいなもの（たとえば、 ENOTBLKを選択することは、エラーがseccompが呼び出しをブロックしたことによるものであることを

tl; dr-並列ループで問題を検出しますが、ループが完了するまで問題の処理を待ちます。 システムコールが失敗したため、ループ内に防御コーディングを追加する必要がある場合があります。

@ kloetzl-問題＃96を調べて、OpenMPでどれだけうまく機能するかを確認します。 それもまた別の解決策かもしれません。 ありがとう！

そして、あなたのプログラムがそれを処理し、ユーザーにエラーを返すものになるので、あなたはあなたに最適なerrnoを選ぶことができます。 実際、あいまいなもの（ENOTBLKなど）を選択することは、エラーがseccompが呼び出しをブロックしたことによるものであることを知る方法である可能性があります。

つまり、 madviseはmalloc腸の奥深くで呼ばれます。 したがって、私はエラーを処理する人ではありません、glibcはそうです。 したがって、問題は、glibc（およびsyscallを実行する他のすべてのライブラリ）は、syscallがmanページに記載されている以外のエラーを返し、適切に処理できることを知っていますか？

問題は、madviseはmallocの腸の奥深くと呼ばれているということです。 したがって、私はエラーを処理する人ではありません、glibcはそうです。 したがって、問題は、glibc（およびsyscallを実行する他のすべてのライブラリ）は、syscallがmanページに記載されている以外のエラーを返し、適切に処理できることを知っていますか？

ああ...お奨め。 確かにglibcコードを調べる必要がありますが、次の推測を危険にさらすことをいとわないでしょう。

• madviseがエラーを返す場合、glibcも_間違いなく_エラーを返します
• glibcが返されたseccompとは異なるエラーを返す可能性があることは間違いありません。したがって、 ENOTBLKような「カスタム」リターンコードを期待している場合は注意が必要です。

簡単に言うと、glibcは_any_エラーコードを抑制すべきではありませんが、代わりに別のエラーコードを返す可能性があります

私はあなたたちに追いつくようにしていますが、OpenMPのバックグラウンドが不足しているために少し遅れているのではないかと心配しています...上記のコメントに基づくと、 KILL_PROCESSはここで実行可能な解決策になる可能性がありますか？ もしそうなら、v2.4リリースの前に対処すべきことの私のリストにありますが、その問題の優先順位を上げることができます。

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

@ pcmoore-はい、 KILL_PROCESSはこのバグの実行可能な解決策だと思います。 上記の@kloetzlのテストプログラムをKILL_PROCESSアクションを使用してテストしましたが、ハングは発生しなくなりました。

私はそれを実装しましたが、現在、Pythonの自動テストでいくつかの問題にぶつかっています。 来週パッチを出す必要があります。

@drakenclimberああ、パッチ？ 私はパッチが大好きです:)

みんなありがとう。

KILL_PROCESSで問題が解決したことを確認できます。Archでローカルバージョンのlibseccompをハッキングしたところ、テストプログラムが意図したとおりに失敗しました。 ただし、確実なテストを提供し、それらを異なるカーネルで実行することは、より大きな課題になる可能性があります。

確認@kloetzlをありがとう。

はい、適切なテストを書くのは面倒ですが、それは重要です。 IMHOをテストするコードと同じくらい重要です。

@drakenclimberからのPRを楽しみにしています。コードが公開されたら、もう少し話し合うことができます。

私はいくつかのCOVID-19春の大掃除をしています、そして私たちはあなたの問題を解決したと思います、それは正しい@kloetzlですか？ この問題をクローズしますが、間違っていても問題が解決しない場合は、お知らせください。再開します。

思い出させてくれてありがとう、私は自分の側で少しテストしました。

この問題はほとんど修正されていますが、小さな問題があります。 無効なシステムコールが発生したときに、プログラムが途方に暮れることはなくなりました。 SCMP_ACT_TRAPすると、不正なシステムコールの名前を生成することもできます。 ただし、OpenMPはシグナルハンドラーを上書きするため、複数のスレッドが生成されると、デフォルトのエラーメッセージにフォールバックします。 ユーザーエクスペリエンスの観点から、私はこの動作が好きではありませんが、それが得られるのと同じくらい良いと思います。

ああ、はい、libseccompでシグナルハンドラが上書きされることについて私たちにできることがたくさんあるかどうかはわかりません。申し訳ありません。

残りの部分が機能したことをお知らせいただきありがとうございます。