Libseccomp: バグ：疑似システムコールのBPFを生成しない

以下の改善されたドラフトを優先して削除されたリプロデューサー

明確にするために、デバッグの目的で、PFCで疑似システムコールを発行する必要がありますが、（役に立たない）BPFフィルタールールを発行するべきではありません。

レポートから問題を作成していただきありがとうございます。

明確にするために、デバッグの目的で、PFCで疑似システムコールを発行する必要がありますが、（役に立たない）BPFフィルタールールを発行するべきではありません。

これを考え直してください。 これは、PFCがBPFを反映しない場合にのみ、事態を複雑にし、曖昧にするだろうと私は信じています。

これを考え直してください。 これは、PFCがBPFを反映しない場合にのみ、事態を複雑にし、曖昧にするだろうと私は信じています。

システムコールがPFCにない場合、ライブラリが（存在しない）システムコールのフィルターを追加できなかった方法について説明する偽のバグレポートが多数届きます。

疑似システムコールの概念を理解している人にとっては、PFC出力からそれらを削除するのは簡単なことです。 また、PFC出力はBPF出力の正確なコピーを意図したものではなく、単にデバッグツールとして存在し、生成されたフィルターコードを視覚化する簡単な方法として存在します。

生成されたフィルターコードを視覚化する簡単な方法

ただし、生成されたコードには疑似システムコールが存在しないため、_生成された_フィルターコードは視覚化されません。

システムコールがPFCにない場合、ライブラリが（存在しない）システムコールのフィルターを追加できなかった方法について説明する偽のバグレポートが多数届きます。

の論理的な違い（条件の有無）よりも、疑似システムコールチェックがコードに存在してはならないことを理解する方がはるかに簡単です（「最適化された」のように、「アーチにはそのようなシステムコールがないため」）。コードと実際のコードの視覚化。

PFCの出力ははるかに読みやすいので、 scmp_bpf_disasmを使用するよりもBPFを反映する方がPFCの方が好きです。

@ vt-altに関するあなたの懸念を理解しています。おそらく将来のリリースでは、PFCでそれを行いますが、PFC出力から疑似システムコールを削除するのは間違いだと思います。

@drakenclimberこれについて強い意見はありますか？

x86_64用に改訂されたリプロデューサー：

#include <stdlib.h>
#include <errno.h>

#include <seccomp.h>

#include "util.h"

int main(int argc, char *argv[])
{
        int rc;
        struct util_options opts;
        scmp_filter_ctx ctx = NULL;

        rc = util_getopt(argc, argv, &opts);
        if (rc < 0)
                goto out;

        ctx = seccomp_init(SCMP_ACT_KILL);
        if (ctx == NULL)
                return ENOMEM;

        rc = seccomp_arch_add(ctx, SCMP_ARCH_X32);
        if (rc < 0)
                goto out;

        rc = seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(access), 0);
        if (rc < 0)
                goto out;
        rc = seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(arm_fadvise64_64), 0);
        if (rc < 0)
                goto out;

        rc = util_filter_output(&opts, ctx);
        if (rc)
                goto out;

out:
        seccomp_release(ctx);
        return (rc < 0 ? -rc : rc);
}

更新：TSKIPの問題を修正しました

まだ完全にはテストされていませんが、これは修正される可能性があります-これが平衡ツリー最適化アルゴリズム@drakenclimberにとって妥当であることを確認できますか？

diff --git a/src/arch-arm.c b/src/arch-arm.c
index 3465111..4dd4b63 100644
--- a/src/arch-arm.c
+++ b/src/arch-arm.c
@@ -54,7 +54,7 @@ int arm_syscall_resolve_name_munge(const char *name)
        if (sys == __NR_SCMP_ERROR)
                return sys;

-       return sys + __SCMP_NR_BASE;
+       return (sys | __SCMP_NR_BASE);
 }

 /**
@@ -68,7 +68,7 @@ int arm_syscall_resolve_name_munge(const char *name)
  */
 const char *arm_syscall_resolve_num_munge(int num)
 {
-       return arm_syscall_resolve_num(num - __SCMP_NR_BASE);
+       return arm_syscall_resolve_num(num & (~__SCMP_NR_BASE));
 }

 const struct arch_def arch_def_arm = {
diff --git a/src/arch-x32.c b/src/arch-x32.c
index 7b97fb3..3890968 100644
--- a/src/arch-x32.c
+++ b/src/arch-x32.c
@@ -43,7 +43,7 @@ int x32_syscall_resolve_name_munge(const char *name)
        if (sys == __NR_SCMP_ERROR)
                return sys;

-       return sys + X32_SYSCALL_BIT;
+       return (sys | X32_SYSCALL_BIT);
 }

 /**
@@ -57,7 +57,7 @@ int x32_syscall_resolve_name_munge(const char *name)
  */
 const char *x32_syscall_resolve_num_munge(int num)
 {
-       return x32_syscall_resolve_num(num - X32_SYSCALL_BIT);
+       return x32_syscall_resolve_num(num & (~X32_SYSCALL_BIT));
 }

 const struct arch_def arch_def_x32 = {
diff --git a/src/gen_bpf.c b/src/gen_bpf.c
index 55a7958..ae9c3f4 100644
--- a/src/gen_bpf.c
+++ b/src/gen_bpf.c
@@ -1555,6 +1555,10 @@ static int _gen_bpf_syscalls(struct bpf_state *state,
        for (s_iter = s_tail; s_iter != NULL; s_iter = s_iter->pri_prv) {
                if (!s_iter->valid)
                        continue;
+               /* skip pseudo-syscalls */
+               if ((s_iter->num & 0x80000000) &&
+                   (state->attr->api_tskip == 0 || s_iter->num != -1))
+                       continue;

                if (*bintree_levels > 0 &&
                    ((syscall_cnt + empty_cnt) % SYSCALLS_PER_NODE) == 0)

@ vt-altに関するあなたの懸念を理解しています。おそらく将来のリリースでは、PFCでそれを行いますが、PFC出力から疑似システムコールを削除するのは間違いだと思います。

@drakenclimberこれについて強い意見はありますか？

実際にはそうではありませんが、問題の根本は、PFC出力が複数の異なる方法で使用されていることだと思います。

1. 上記のように、これは新しい（より）ユーザーがフィルターを大まかに確認するための簡単な方法です
2. より上級のユーザーは、それが実際のBPFフィルターの近似値であると期待しています。

おそらく、PFCロジックに--no-pseudo-syscallsフラグを追加できますか？ そうすれば、初心者ユーザーにとっては同じままですが、上級ユーザーはBPFのより良い近似を得ることができます。

_UPDATED：TSKIPの問題を修正しました_

まだ完全にはテストされていませんが、これは修正される可能性があります-これが平衡ツリー最適化アルゴリズム@drakenclimberにとって妥当であることを確認できますか？

しましょう。 このシナリオを再現する自動テストを作成できるかどうかを確認したいと思います。

_UPDATED：TSKIPの問題を修正しました_
まだ完全にはテストされていませんが、これは修正される可能性があります-これが平衡ツリー最適化アルゴリズム@drakenclimberにとって妥当であることを確認できますか？

しましょう。 このシナリオを再現する自動テストを作成できるかどうかを確認したいと思います。

そしてもちろん、私はあなたが上で持っている再生器テストから始めます。 ありがとう！

_UPDATED：TSKIPの問題を修正しました_

まだ完全にはテストされていませんが、これは修正される可能性があります-これが平衡ツリー最適化アルゴリズム@drakenclimberにとって妥当であることを確認できますか？

バイナリツリーは、アキュムレータを変更する必要がある場合に事前に計算します。これにより、 jgeロジックを挿入することがわかります。 フィルタの構築中に（上記の提案のように）システムコールをヤンクアウトすると、このロジックが壊れます。

私もまだ完全に変更をテストしていません:)が、疑似システムコールを削除してバイナリツリーを機能させるには、このようなものが必要になると確信しています。 私はこれを使用してBPF二分木を生成しました、そしてそれは合理的に見えます。 本番環境に対応したソリューションに近づいたら、完全に検証します。

@@ -1532,11 +1532,31 @@ static int _gen_bpf_syscalls(struct bpf_state *state,
                _sys_sort(db_secondary->syscalls, &s_head, &s_tail, optimize);

        if (optimize == 2) {
+               /* since pseudo-syscalls are removed from the filter, we need
+                * to calculate the syscall count by hand
+                */
+               for (s_iter = s_tail; s_iter != NULL; s_iter = s_iter->pri_prv) {
+                       if (!s_iter->valid)
+                               continue;
+
+                       /* skip pseudo-syscalls */
+                       if ((s_iter->num & 0x80000000) &&
+                           (state->attr->api_tskip == 0 || s_iter->num != -1))
+                               continue;
+
+                       syscall_cnt++;
+               }
+
                rc = _gen_bpf_init_bintree(&bintree_hashes, &bintree_syscalls,
-                                          bintree_levels, db->syscall_cnt,
+                                          bintree_levels, syscall_cnt,
                                           &empty_cnt);
                if (rc < 0)
                        goto out;
+
+               /* reset the syscall_cnt variable because later in this
+                * function it's used as a counter
+                */
+               syscall_cnt = 0;
        }

db構造体に「有効な」システムコール数を追跡する変数がある場合、これをよりスマート/高速にすることができます。

おそらく、PFCロジックに--no-pseudo-syscallsフラグを追加できますか？

この旗はどこに行きますか？ ビルド時のオプションとしてこれを望んでいないと思います。 フィルタオプションを追加できると思いますが、あまり興奮していません。 私はPFCの疑似システムコールに固執することに投票しますが、今のところBPFから削除します（明らかに）。将来のある時点でこれを拡張する必要がある場合は可能です。

私もまだ完全に変更をテストしていません:)が、疑似システムコールを削除してバイナリツリーを機能させるには、このようなものが必要になると確信しています。 私はこれを使用してBPF二分木を生成しました、そしてそれは合理的に見えます。 本番環境に対応したソリューションに近づいたら、完全に検証します。

これがツリーの最適化を壊してしまうのではないかと思いました。

@drakenclimberは、これが標準の最適化よりもツリーの並べ替えに大きな影響を与えることを考慮しています。この問題を取り上げますか？ 上にコピーして貼り付けたコードを、意味のある範囲で自由に盗んでください。

関係なくやるべきだと思うことの1つは、「arch-arm.c」と「arch-x32.c」の変更がより理にかなっていることです。

おそらく、PFCロジックに--no-pseudo-syscallsフラグを追加できますか？

この旗はどこに行きますか？ ビルド時のオプションとしてこれを望んでいないと思います。 フィルタオプションを追加できると思いますが、あまり興奮していません。 私はPFCの疑似システムコールに固執することに投票しますが、今のところBPFから削除します（明らかに）。将来のある時点でこれを拡張する必要がある場合は可能です。

思った前にタイプしたことは認めます。 ;）

ええ、それはフィルターオプションでなければならないでしょう、そしてそれは間違っていると感じます。 同意します; 上で概説したようにしましょう。 引き続き質問があれば、再訪することができます。

私もまだ完全に変更をテストしていません:)が、疑似システムコールを削除してバイナリツリーを機能させるには、このようなものが必要になると確信しています。 私はこれを使用してBPF二分木を生成しました、そしてそれは合理的に見えます。 本番環境に対応したソリューションに近づいたら、完全に検証します。

これがツリーの最適化を壊してしまうのではないかと思いました。

@drakenclimberは、これが標準の最適化よりもツリーの並べ替えに大きな影響を与えることを考慮しています。この問題を取り上げますか？ 上にコピーして貼り付けたコードを、意味のある範囲で自由に盗んでください。

関係なくやるべきだと思うことの1つは、「arch-arm.c」と「arch-x32.c」の変更がより理にかなっていることです。

もちろん。 私はこれを所有することができます。

@drakenclimber ">前述のように、これは、新しい（より）ユーザーがフィルターを大まかに検証するための簡単な方法です。」

「疑似システムコール」はカーネルに存在せず、よく知られた概念でもありません。 これは純粋にlibseccompの発明であり、ここでは説明しません。 それらは負の数であり、指定されたsyscallがアーキテクチャに存在しない場合に表示されると述べただけです。 これは存在しないシステムコールとどう違うのですか？ 彼らはどのような目的で否定的ですか？ 疑似システムコールの概念は、新しいユーザーにとっては本当に混乱を招きます。

新しい（より）ユーザーが、存在しないシステムコールがフィルターでチェックされているのを見たいと思っているなんて信じられません。

もう一点付け加えさせていただきます。 これはすべてセキュリティの分野であり、注意深く詳細な理解のみが機能します。 （疑似システムコールの）新しいあいまいな概念と、表現（bpfとpfc）の違いを作成します。 これは本当に新しいユーザーを混乱させるためのものですか？

@ vt-alt懸念を表明していただきありがとうございますが、v2.5.0リリースでは、BPFフィルターからの疑似システムコールを抑制し、引き続きPFCフィルターに表示します。 この決定に同意できない場合があることは承知しておりますが、この決定を尊重していただきますようお願いいたします。 将来のリリースでは、疑似システムコールの背後にある目的（複数のABIサポート用）を説明し、マンページに文書化することで、より良い仕事をする予定です。 そのための問題を作成しました（以下のリンク）。そのディスカッションと結果として生じるPRに参加することを歓迎し、奨励します。 将来的にはPFCフィルターへのアプローチを修正することも可能ですが、ここでは何も約束したくありません。

• https://github.com/seccomp/libseccomp/issues/258

繰り返しになりますが、BPFの問題に注意を向けていただきありがとうございます。 あなたは次のlibseccompリリースを改善するのを手伝ってくれました！

＃264で締めくくります。