Libseccomp: バグ：SCMP_CMP_GT / GE / LT / LEが負のsyscall引数に対して期待どおりに機能しない

問題の報告をありがとう。 それは良いことです。

万が一、カーネルのsamples / seccompディレクトリにあるheaders / macrosを使用して

カーネルのBPFコードが即値を署名付きとして扱っているという印象を受けました。 そうでないかもしれません、または私はlibseccompコードで何かを台無しにしたかもしれません。

FWIW、BPF自体は引数にu32を使用します。 libseccompはcompat引数の符号拡張を行いますか？ （おそらくそうすべきではありませんが、「-1」に一致するルールは32ビットと64ビットで異なる必要があります...）

今私が心配している問題は、ジャンプ演算子でのBPF GT / GEの比較です。特に、ほとんどの人がBPFをこれらの比較の符号付きの値として即時に扱っていると思われるためです。

@keesカーネルのseccomp-bpfマシンとsyscall引数の符号付き比較を行うための推奨されるアプローチは何ですか？ 「最初にハイビットをチェックしてから、負の数を比較する前に必要な2の補数変換を行う」という方針に沿ったものではないことを願っています。 煩わしいことですが、必要なBPFを生成するようにlibseccompをいつでも変更できます（ただし、生成されるフィルターがはるかに大きくなる場合もあります）が、独自のBPFフィルターを作成するアプリケーションについて心配しています。 これを正しく処理する確率はおそらくあまり良くありません。

残念ながら、syscall引数は「unsignedlong」であるため（syscall_get_arguments（）およびstruct seccomp_dataを参照）、syscallが符号変換を処理する方法について一般的なケースはありません。 互換性バリアを通過するときの一部のシステムコールは符号拡張を行いますが、他のシステムコール（prctl）は行いません。 マイナスではあるがマイナス1ではないsyscall引数がたくさんありますか？

今日これに戻り、今朝もう少し遊んだので、これはドキュメント/「注意してください！」になると思います。 特に既存のユーザーについて話しているときは、良い解決策がないため、問題が発生します。 カーネル側からの@keesの役立つコメントに沿って、

FWIW、BPF自体は引数にu32を使用します。 libseccompはcompat引数の符号拡張を行いますか？ （おそらくそうすべきではありませんが、「-1」に一致するルールは32 [ビットと64ビットの間で異なる必要があります...）

libseccomp APIルール関数は、すべての即値を_uint64_t_として解釈するため、タイプ/キャストに不注意な場合は問題が発生する可能性があります。 例：

$ cat 00-test.c
    /* ... */
    seccomp_rule_add_exact(ctx, SCMP_ACT_KILL, 1000, 1,
                           SCMP_A0(SCMP_CMP_GT, -1));
    seccomp_rule_add_exact(ctx, SCMP_ACT_KILL, 1001, 1,
                           SCMP_A0(SCMP_CMP_GT, (uint32_t)-1));
    seccomp_rule_add_exact(ctx, SCMP_ACT_KILL, 1002, 1,
                           SCMP_A0(SCMP_CMP_GT, 0xffffffff));
    /* ... */
$ make 00-test
  CC       00-test.o
  CCLD     00-test
$ ./00-test -p
  #
  # pseudo filter code start
  #
  # filter for arch x86_64 (3221225534)
  if ($arch == 3221225534)
    # filter for syscall "UNKNOWN" (1002) [priority: 65533]
    if ($syscall == 1002)
      if ($a0.hi32 >= 0)
        if ($a0.lo32 > 4294967295)
          action KILL;
    # filter for syscall "UNKNOWN" (1001) [priority: 65533]
    if ($syscall == 1001)
      if ($a0.hi32 >= 0)
        if ($a0.lo32 > 4294967295)
          action KILL;
    # filter for syscall "UNKNOWN" (1000) [priority: 65533]
    if ($syscall == 1000)
      if ($a0.hi32 >= 4294967295)
        if ($a0.lo32 > 4294967295)
          action KILL;
    # default action
    action ALLOW;
  # invalid architecture action
  action KILL;
  #
  # pseudo filter code end
  # 
$ ./00-test -b | ../tools/scmp_bpf_disasm 
   line  OP   JT   JF   K
  =================================
   0000: 0x20 0x00 0x00 0x00000004   ld  $data[4]
   0001: 0x15 0x00 0x0c 0xc000003e   jeq 3221225534 true:0002 false:0014
   0002: 0x20 0x00 0x00 0x00000000   ld  $data[0]
   0003: 0x35 0x0a 0x00 0x40000000   jge 1073741824 true:0014 false:0004
   0004: 0x15 0x00 0x02 0x000003e8   jeq 1000 true:0005 false:0007
   0005: 0x20 0x00 0x00 0x00000014   ld  $data[20]
   0006: 0x35 0x04 0x06 0xffffffff   jge 4294967295 true:0011 false:0013
   0007: 0x15 0x01 0x00 0x000003e9   jeq 1001 true:0009 false:0008
   0008: 0x15 0x00 0x04 0x000003ea   jeq 1002 true:0009 false:0013
   0009: 0x20 0x00 0x00 0x00000014   ld  $data[20]
   0010: 0x35 0x00 0x02 0x00000000   jge 0    true:0011 false:0013
   0011: 0x20 0x00 0x00 0x00000010   ld  $data[16]
   0012: 0x25 0x01 0x00 0xffffffff   jgt 4294967295 true:0014 false:0013
   0013: 0x06 0x00 0x00 0x7fff0000   ret ALLOW
   0014: 0x06 0x00 0x00 0x00000000   ret KILL

...ご覧のとおり、適切なキャストを使用すると、値は符号拡張されません。 しかし、これはほとんどの人がしていることではないと思います。 良いニュースは、否定的な議論をするシステムコールの数が比較的少ないと想像しているので、影響はある程度制限されるべきです。

今後は、これに関するドキュメントに何かを入れて、開発者の生活を楽にするために何かできるかどうかを確認する必要があります。おそらく、_SCMP_A * _マクロの32ビットバリアントを実装します。

@ pcmoore-詳細な回答に感謝し、すぐに戻ってこないことをお詫びします。 いいえ、 https：//github.com/torvalds/linux/tree/master/samples/seccompに基づいて

@jdstrand当分の間、私たちは皆準備が

それまでの間、適切に型変換された値で問題が発生した場合は、この問題を更新してください。

良いニュースは、否定的な議論をするシステムコールの数が比較的少ないと想像しているので、影響はある程度制限されるべきです。

openat（）のfdパラメーターが-100である特別な値AT_FDCWDに等しいかどうかを（とりわけ）チェックするときに、この問題に遭遇しました。 これにより、次のことが可能になります。

  # filter for syscall "openat" (257) [priority: 131067]
  if ($syscall == 257)
    if ($a0.hi32 == 4294967295)
      if ($a0.lo32 == 4294967196)
        if ($a2.hi32 & 0x00000000 == 0)
          if ($a2.lo32 & 0x00000003 == 0)
            action ERRNO(2);

あるべき場所：

  # filter for syscall "openat" (257) [priority: 131067]
  if ($syscall == 257)
    if ($a0.hi32 == 0)
      if ($a0.lo32 == 4294967196)
        if ($a2.hi32 & 0x00000000 == 0)
          if ($a2.lo32 & 0x00000003 == 0)
            action ERRNO(2);

glibc 2.26+は、openatsyscallとAT_FDCWDを排他的に使用してopen（）を実装しているように見えるため、これは多くの人をつまずかせる可能性があります。 上記のようにuint32_tにキャストを適用すると、問題が修正されました。

        // selector, action, syscall, no of args, args
        { SEL, SCMP_ACT_ERRNO(ENOENT), "openat", 2,
-               { SCMP_A0(SCMP_CMP_EQ, AT_FDCWD), /* glibc 2.26+ */
+               { SCMP_A0(SCMP_CMP_EQ, (uint32_t)AT_FDCWD), /* glibc 2.26+ */
                  SCMP_A2(SCMP_CMP_MASKED_EQ, O_ACCMODE, O_RDONLY) }},

明示的なSCMP_A0_U32があると便利です。

@drakenclimber @jdstrand @michaelweiser君たちはどう思いますかhttps://github.com/pcmoore/misc-libseccomp/commit/b9ce39d776ed5a984c7e9e6db3b87463edce82a7このための修正として？

@pcmoore ：これを調査し続けてくれてありがとう！ 私はそれに旋風を与えました、そしてそれはコードで本当に素晴らしく見えます：

static struct {
        const uint64_t promises;
        const uint32_t action;
        const char *syscall;
        const int arg_cnt;
        const struct scmp_arg_cmp args[3];
} scsb_calls[] = {
[...]
        { PLEDGE_WPATH, SCMP_ACT_ALLOW, "openat", 2, /* glibc 2.26+ */
                { SCMP_A0_32(SCMP_CMP_EQ, AT_FDCWD),
                  SCMP_A2_64(SCMP_CMP_MASKED_EQ, O_ACCMODE, O_WRONLY) }},

残念ながら、ヘルパー関数は構造体初期化子としては適切ではないようです。

In file included from pledge.c:42:
/include/seccomp.h:230:26: error: initializer element is not constant
 #define SCMP_CMP32(...)  (__scmp_arg_32(SCMP_CMP64(__VA_ARGS__)))
                          ^
/include/seccomp.h:241:26: note: in expansion of macro ‘SCMP_CMP32’
 #define SCMP_A0_32(...)  SCMP_CMP32(0, __VA_ARGS__)
                          ^~~~~~~~~~
pledge.c:188:5: note: in expansion of macro ‘SCMP_A0_32’
   { SCMP_A0_32(SCMP_CMP_EQ, AT_FDCWD),
     ^~~~~~~~~~
/include/seccomp.h:230:26: note: (near initialization for ‘scsb_calls[21].args[0]’)
 #define SCMP_CMP32(...)  (__scmp_arg_32(SCMP_CMP64(__VA_ARGS__)))
                          ^
/include/seccomp.h:241:26: note: in expansion of macro ‘SCMP_CMP32’
 #define SCMP_A0_32(...)  SCMP_CMP32(0, __VA_ARGS__)
                          ^~~~~~~~~~
pledge.c:188:5: note: in expansion of macro ‘SCMP_A0_32’
   { SCMP_A0_32(SCMP_CMP_EQ, AT_FDCWD),
     ^~~~~~~~~~

レビュー@michaelweiserに感謝します。残念ながら、このマクロを初期化子として使用しているとは思いませんでしたが、これは有効な使用法であり、この方法で使用している人は確かに少数です。

これについて少し考える必要があります...これをエレガントな方法で解決する方法について何かアイデアはありましたか？

わからない、すみません、私はすでにマッチで目を開いていました。 :)

今それを見ると、問題が発生していると思います。可変引数リストが原因で、必要なキャストを挿入できません。

scmp_arg_cmpには、正しい幅、配置（さらにはバイト順序）でデータに対してさまざまなビューを提供するユニオンが含まれている可能性があります（IMOは「エレガント」と競合します）。 それが純粋にlibseccompの内部にあり、カーネルインターフェースと互換性がある必要がない場合、データ型インジケーターを別個のフィールドとして運び、ユーザー関数にそれを分類させることができますか？ そして、それは可変引数を使用して初期化することさえできますか？

それ以外の場合は、操作を32/64ビット全体としてマークする代わりに、オペランドに注釈を付けて、キャストをラップし、デバッグが困難な問題に遭遇した場合のペナルティで常にこれらの注釈を使用するようにユーザーに厳しい推奨を与えることができます。 ？

{ SCMP_A0(SCMP_CMP_EQ, SCMP_OP_32(AT_FDCWD)),
  SCMP_A2(SCMP_CMP_MASKED_EQ, SCMP_OP_64(O_ACCMODE), SCMP_OP_64(O_WRONLY)) }},

また

{ SCMP_A0(SCMP_CMP_EQ, SCMP_OP1_32(AT_FDCWD)),
  SCMP_A2(SCMP_CMP_MASKED_EQ, SCMP_OP2_64(O_ACCMODE, O_WRONLY)) }},

申し訳ありませんが、プリプロセッサのクラックでもっと多くのことを思いつくのに十分ではありません。

@pcmoore 、変更は私にはよく見えます。 私はプリプロセッサの専門家ではありませんが、 @ michaelweiserが前述した問題を見ていきます。

今それを見ると、問題が発生していると思います。可変引数リストが原因で、必要なキャストを挿入できません。

うん、それはほとんどそれです。 恐ろしい方法はないかもしれませんが、まだ見つけていません。

scmp_arg_cmpには、正しい幅、配置（さらにはバイト順序）でデータに対してさまざまなビューを提供するユニオンが含まれている可能性があります（IMOは「エレガント」と競合します）。 それが純粋にlibseccompの内部にあり、カーネルインターフェースと互換性がある必要がない場合、データ型インジケーターを別個のフィールドとして運び、ユーザー関数にそれを分類させることができますか？ そして、それは可変引数を使用して初期化することさえできますか？

scmp_arg_cmp構造体がlibseccompAPIの一部であるという問題があるため、libseccompメジャーバージョンをバンプしたい場合を除いて、構造体のサイズやメンバーフィールドのオフセットを実際に変更することはできません。 これを行うと、既存のアプリケーションとの既存のバイナリインターフェイスが破損します。 64ビットのデータムフィールドを64ビットまたは32ビットの値を含むユニオンに変換すること自体は問題ありませんが、scmp_arg_cmp構造体に追加情報を追加して、使用するユニオンメンバーを示す必要もあります。 ; 問題になる可能性があるのは、この余分なフラグです。

「arg」または「op」フィールドのいずれかから一部のビットを盗むことが可能である可能性があります。どちらも32ビット値であり、そのスペースのごく一部しか使用していません。 しかし、私はそれをかなり極端な選択肢だと考えており、可能であればそれを避けたいと思います。

それ以外の場合は、操作を32/64ビット全体としてマークする代わりに、オペランドに注釈を付けて、キャストをラップし、デバッグが困難な問題に遭遇した場合のペナルティで常にこれらの注釈を使用するようにユーザーに厳しい推奨を与えることができます。 ？

オペランドをマクロでラップすることで何が得られるのかよくわかりませんが、もう少し詳しく説明していただけますか？ データム値をラップするマクロを提供することもできますが、それは、呼び出し元に適切なキャストを提供するように要求することと実際には何の違いもありません。

@pcmoore 、変更は私にはよく見えます。 私はプリプロセッサの専門家ではありませんが、 @ michaelweiserが前述した問題を見ていきます。

まことにありがとうございます。 うまくいけば、私たち3人の間で、ここで役立つ何かを思いつくことができます。

@pcmoore ： http ： //efesx.com/2010/07/17/variadic-macro-to-count-number-of-arguments/およびhttp://efesx.com/2010/08/31/overloading-を見て

#define VA_NUM_ARGS(...) VA_NUM_ARGS_IMPL(__VA_ARGS__, 5,4,3,2,1)
#define VA_NUM_ARGS_IMPL(_1,_2,_3,_4,_5,N,...) N
#define macro_dispatcher(func, ...) \
            macro_dispatcher_(func, VA_NUM_ARGS(__VA_ARGS__))
#define macro_dispatcher_(func, nargs) \
            macro_dispatcher__(func, nargs)
#define macro_dispatcher__(func, nargs) \
            func ## nargs

#define SCMP_CMP64(...)         ((struct scmp_arg_cmp){__VA_ARGS__})

#define SCMP_CMP32_1(x)                 SCMP_CMP64(x)
#define SCMP_CMP32_2(x, y)              SCMP_CMP64(x, y)
#define SCMP_CMP32_3(x, y, z)           SCMP_CMP64(x, y, (uint32_t)(z))
#define SCMP_CMP32_4(x, y, z, q)        SCMP_CMP64(x, y, (uint32_t)(z), (uint32_t)(q))
#define SCMP_CMP32(...) macro_dispatcher(SCMP_CMP32_, __VA_ARGS__)(__VA_ARGS__)

#define SCMP_A0_64(...)         SCMP_CMP64(0, __VA_ARGS__)
#define SCMP_A0_32(...)         SCMP_CMP32(0, __VA_ARGS__)

このテストケースの場合：

        struct scmp_arg_cmp f[] = {
                SCMP_A0_64(SCMP_CMP_EQ, 1, 20),
                SCMP_A0_32(SCMP_CMP_EQ, 2, 3),
                SCMP_A0_32(SCMP_CMP_LT, 2),
        };

gcc-7.4.0 -Eとclang-7 -Eようになります。

 struct scmp_arg_cmp f[] = {
  ((struct scmp_arg_cmp){0, SCMP_CMP_EQ, 1, 20}),
  ((struct scmp_arg_cmp){0, SCMP_CMP_EQ, (uint32_t)(2), (uint32_t)(3)}),
  ((struct scmp_arg_cmp){0, SCMP_CMP_LT, (uint32_t)(2)}),
 };

SCMP_A[0-5]_43が機能するには少なくともop SCMP_A[0-5]_43が必要であり、 SCMP_CMP32がarg必要とするという仮定の下で、これらのパラメーターを定位置にすることで2行を節約できます。

#define SCMP_CMP32_1(x, y, z)           SCMP_CMP64(x, y, (uint32_t)(z))
#define SCMP_CMP32_2(x, y, z, q)        SCMP_CMP64(x, y, (uint32_t)(z), (uint32_t)(q))
#define SCMP_CMP32(x, y,...)            macro_dispatcher(SCMP_CMP32_, __VA_ARGS__)(x, y, __VA_ARGS__)

#define SCMP_A0_32(x,...)       SCMP_CMP32(0, x, __VA_ARGS__)

よくやった@michaelweiser！ 変更を少し簡単に確認/コメントできるように、PRをまとめたいですか？ そうでない場合、それは完全に問題ありません、私は1つを一緒に投げて、あなたが十分な信用を得ることを確認します:)

今夜のPRを作ります。 https://github.com/pcmoore/misc-libseccomp/commit/b9ce39d776ed5a984c7e9e6db3b87463edce82a7の上に、または最初から？
Blogger Romanの過負荷ソリューションをどのように評価しますか？ https://kecher.net/overloading-macros/で彼のブログの現在のホームと思われるものを見つけましたmacro_dispatcherロジックの上の投稿へのリンクを付けてコメントしますか？

今夜のPRを作ります。 pcmoore @ b9ce39dの上に、または最初から？

よかった。ありがとう！ 先に進んで、masterブランチに基づいてください。私は、misc-libseccompツリーの内容をマージしたことはありません。また、アプローチがはるかに優れているため、現時点ではマージする予定はありません。

Blogger Romanの過負荷ソリューションをどのように評価しますか？ https://kecher.net/overloading-macros/で彼のブログの現在のホームと思われるものを見つけましたmacro_dispatcherロジックの上の投稿へのリンクを付けてコメントしますか？

ライセンス要件がない限り、通常、ソースに直接クレジットを付与することはありません。 パッチの説明にコメントを追加して、Romanの基本的な考え方を評価し、彼のブログ投稿へのリンクを提供することをお勧めします。 彼の例にはライセンスや制限が課されていないので、その点で問題はないと思います。彼のブログのサンプリングに基づいて、彼の意図はこれらのアイデアを他の人（私たちのような）と共有することだと思います）彼らが彼らの問題を解決するのを助けるために。 Romanのメールアドレスをお持ちの場合は、いつでも彼にメールを送信してみてください。 なんらかの理由で彼に連絡が取れない場合は、先に進んでも大丈夫だと思います。

80a987d6f8d0152def07fa90ace6417d56eea741を介して解決されました。