Libseccomp: バグ：gen_bpf_generate（）が失敗を適切に処理しない

こんにちは@Xyene 、

seccomp_load（）コードパスで-EINVALを返す場所は多くありません。 libseccomp v2.4.3コードの簡単な調査に基づくと、無効なscmp_filter_ctxか、フィルターをロードするprctl(...)呼び出しについてカーネルが文句を言っていることが原因のようです。

v2.4.3が一般的に機能し、カーネルを変更していないことを考えると、 prctl(...)呼び出しが、無効なフィルターコンテキストにつながる原因であるかどうかは疑わしいようです。 アップグレード以降、プログラムに他の奇妙な動作があることに気づきましたか？ 問題を引き起こしている他の場所でメモリ破損の問題があるかどうか疑問に思います。

libseccompに障害がある可能性は常にありますが、すべての回帰テストのvalgrind実行、およびclangとCoverityの両方を使用した静的分析を含む一連のチェックを通じて、各リリースを実行します。

また、これはv2.4.3には役立ちませんが、ほぼ準備が整ったv2.5.0リリースで目標としている改善の1つは、ドキュメントとエラーコードの処理の改善です。

最近、Dockerコンテナのパッケージをアップグレードしました。これには、libseccomp 2.3.3（Debian安定リポジトリのバージョン）から2.4.3へのアップグレードが含まれています。 他にもアップグレードされたシステムパッケージがありましたが、私はそれらを記録しませんでした。 私たちのカーネルはアップグレードされておらず、バージョン4.19.0-8-amd64です。

コードと基盤となるカーネルが変更されていないことを確認していただきありがとうございます。 それは問題を追跡するのに役立つはずです。

参考までに、これは、 seccomp_rule_addマニュアルページと同様のエラーチェックを使用した、seccomp初期化ルーチン全体です。

あなたのフィルターは私には合理的に見えます。

何がうまくいかない可能性があるか（または何がうまくいかないかをさらに掘り下げる方法）、またはこれが何らかの形で予想されるかどうかについてのアイデアはありますか？ 動的な可動部品はそれほど多くなく、なぜこれが発生するのかについてのドキュメントには何も見つかりませんでした。

v2.4.3 seccomp_load()コードを調べましたが、libseccompが-EINVAL戻りコードを生成する場所は2つしかないと思います。

• 283行目のseccomp_load()
• 1657行目の_gen_bpf_build_bpf()

上記のエラーは両方とも、無効なフィルターが原因で発生します。 あなたのフィルターコードに基づいて、それは私にはありそうもないようです。

seccomp_set_mode_filter()でのカーネルのデフォルトの戻り値は-EINVALであることに注意してください。そのため、システム上の他の何かが変更され、そのパスに陥る可能性があります。 Dockerで実行しているとおっしゃっています。 デフォルトのDockerseccompフィルターを無効にしますか？

seccomp_load()が失敗した後、if内のコードにデバッグを追加したくなるでしょう。 たとえば、フィルター自体のPFCやBPFを出力して、適切に見えることを確認できます。 seccomp_export_pfc()およびseccomp_export_bpf()参照してください。

v2.4.3 seccomp_load()コードを調べたところ、libseccompが-EINVAL戻りコードを生成する場所は2つしかないと思います。

• 283行目のseccomp_load()
• 1657行目の_gen_bpf_build_bpf()

gen_bpf_generate(...)以下で見つかった障害は、 src / system.c：267でsys_filter_load(...)によって-ENOMEMに効果的に結合されることに注意してください。

「メモリの破損」に戻るのは嫌いだ。 とても速いですが、ここではそうかもしれません。

迅速で詳細な返信をありがとう！ 彼らは探索のいくつかの道を生み出しました：slightly_smiling_face：

アップグレード以降、プログラムに他の奇妙な動作があることに気づきましたか？ 問題を引き起こしている他の場所でメモリ破損の問題があるかどうか疑問に思います。

いいえ、これだけです。 私たちのユニットテストと統合テストは引き続き合格し、この非常にまれなEINVALを除いて、エラーは製品に記録されていません。 これは確かにそれを不可解にします。 私もメモリの破損を疑ったが、それを裏付ける証拠を見つけることができなかった：slightly_frowning_face：

もう少しコンテキストについて：

• このプログラムは、Cythonを介して一部のC ++を呼び出すPythonアプリです（GILはこの期間中に保持されるため、Pythonは他のスレッドに割り当てを行いません）
• C ++サイドフォーク、および子でexecの前にseccompフィルターを設定します
• フォーク後、実行前に発生するすべてのメモリ割り当ては、 seccomp_initなどのlibseccomp自体からのものです。
• C ++コードの呼び出しとフォークオフの間には正確に4つの配列mallocがあり、それらはすべてCythonにあり、それらに書き込むときに適切な範囲があります（435行目は以前にリンクされたseccompコードを呼び出します）-他のすべての割り当て/書き込みなど。 Pythonインタープリター内にあります

これを入力しているときに、私は考えました。フォーク後にmallocを使用するのは安全ではないというホラーストーリーを聞いたことがありますが、libseccomp自体にいくつかあります。 Pythonアプリ自体はマルチスレッドですが、ネイティブコードでは常にGILを保持するため、これは安全である必要があります（？）。 ただし、malloc-after-forkでデッドロックが発生していると聞いたことがあります。 （これにより、次の注文のビジネスがseccomp_initフォークの前に移動し、フォーク後にseccomp_load呼び出すだけで、エラーが発生し続けるかどうかを確認できると思います。）

seccomp_load（）が失敗した後、if内のコードにデバッグを追加したくなるでしょう。

提案をありがとう！ seccomp_export_pfcへの呼び出しを追加し、入力の内容をフィルター（ config->syscall_whitelist ）にダンプしました。 次回これが失敗したときにフォローアップします。

こんにちは@ Xyene-約1週間が

残念ながら、まだです。 seccomp_export_pfcにパッチを追加した後、それは無音になりました。 昨日、問題が最終的に発生したときに問題をキャプチャすることを期待して、そのパッチを（単なるテストではなく）すべてのVMにプッシュしました。

沈黙は奇妙だと思いますが、すべてのデバッグ/エクスポートロジックはseccomp_load失敗後に発生するため、今のところ偶然にそれをチョークしています。したがって、失敗自体に影響を与えることはないはずです。

進捗！

沈黙している理由は、 seccomp_export_bpfがsegfaultingであり（ seccomp_load後に呼び出された場合は？）、seccompの失敗を探していた場所ではなく、他の場所で報告されていたためです。 さらに重要なことに、約150回の呼び出しで問題を確実に再現できるケースに遭遇したため、配管作業を行うことで、いくつかのコアダンプを抽出できるはずです。

了解しました。コアダンプを取り出しました。これがトレースでした： https ：

jemallocのreallocルーチン内でクラッシュしているため、これは少し疑わしいもの

次に、jemallocを取得し、 -O0とデバッグシンボルを使用してコンパイルし、複製を再実行しました。 今回は、後ではなくseccomp_loadでクラッシュしました。 そのトレースをここにアップロードしました： https ：

そのトレースのスニペット：

#9  0x00007ff962698495 in free (ptr=0x5a5a5a5a5a5a5a5a) at src/jemalloc.c:2867
No locals.
#10 0x00007ff96062d087 in _program_free (prg=prg@entry=0x7ff95e963010) at gen_bpf.c:511
No locals.
#11 0x00007ff96062f605 in gen_bpf_release (program=program@entry=0x7ff95e963010) at gen_bpf.c:1986
No locals.
#12 0x00007ff96062c04f in sys_filter_load (col=col@entry=0x7ff95e9a5000) at system.c:293
        rc = -1
        prgm = 0x7ff95e963010
#13 0x00007ff96062b666 in seccomp_load (ctx=ctx@entry=0x7ff95e9a5000) at api.c:286
        col = 0x7ff95e9a5000

jemallocを検索すると、 0x5aが空きバイトを空きとしてマークするために使用されているように見えます。これは、すでに解放されているものを解放しようとしているコードをクラッシュさせるという特定の目的です。

v2.4.3のgen_bpf.c:511は次のとおりです： https ：

しかし、プログラムの存続期間はsys_filter_load本体にすぎないため、これはあまり意味がありません。

https://github.com/seccomp/libseccomp/blob/1dde9d94e0848e12da20602ca38032b91d521427/src/system.c#L260 -L296

私は少なくとも1つの問題を見つけたと思います。 gen_bpf_generate ;

https://github.com/seccomp/libseccomp/blob/1dde9d94e0848e12da20602ca38032b91d521427/src/gen_bpf.c#L1963 -L1966

state.bpf = prgm zmallocが失敗しない限り、 _gen_bpf_build_bpfが呼び出され、そのrcに基づいて、 state.bpfがNULL設定されます。

https://github.com/seccomp/libseccomp/blob/1dde9d94e0848e12da20602ca38032b91d521427/src/gen_bpf.c#L1968 -L1971

rc != 0の場合を考えると、 _state_release呼び出し時に、 state.bpfはまだprgmれています。 これにより、 prgmが指すメモリが解放されます。

https://github.com/seccomp/libseccomp/blob/1dde9d94e0848e12da20602ca38032b91d521427/src/gen_bpf.c#L539

次に、 gen_bpf_generateはreturn prgmになります。これは解放されたにもかかわらず、ゼロ以外のポインターのままです。

https://github.com/seccomp/libseccomp/blob/1dde9d94e0848e12da20602ca38032b91d521427/src/gen_bpf.c#L1971 -L1974

sys_filter_loadに戻ると、 gen_bpf_generateが返され、 prgmはNULLないため、続行されます。

https://github.com/seccomp/libseccomp/blob/1dde9d94e0848e12da20602ca38032b91d521427/src/system.c#L265 -L267

最後に、 sys_filter_loadの終わりに、すでに無料のprgmでgen_bpf_releaseが呼び出されます。

https://github.com/seccomp/libseccomp/blob/1dde9d94e0848e12da20602ca38032b91d521427/src/system.c#L292 -L295

これは、なぜ_gen_bpf_build_bpfが最初に失敗するのかという懸念に対処していませんが、失敗した場合に発生する可能性のある何か悪いことのように見えます。

編集：実際には、これはおそらくhttps://github.com/seccomp/libseccomp/commit/3a1d1c977065f204b96293cccfe7d3e5aa0d7aceの副作用として修正されたよう

rc！= 0の場合を考えると、state.bpfは_state_releaseの呼び出し時にまだprgmに設定されています。 これにより、prgmが指すメモリが解放されます。

あはは！ グッドキャッチ@Xyene！

これを3a1d1c977065f204b96293cccfe7d3e5aa0d7aceを超えて修正する必要があると思います。これについて少し考えさせてください...修正がそれほど難しくないと思います...そして、PRを考え出すことができるかどうかを確認してください。

これを3a1d1c9を超えて修正する必要があると思います。これについて少し考えさせてください...修正がそれほど難しくないと思います...そして、PRを考え出すことができるかどうかを確認してください。

おっと、私がそれを書いたとき、私は古いコードを見ていました。 はい、3a1d1c9でこれが修正されると思いますが、release-2.4ブランチのパッチが必要になります。 今から取り組んでいきます。

_（メタ：私はこのメッセージを調査結果で更新し続けるつもりなので、メールでスパムを送信せずにそれらを書き留める場所があります：）_

了解しました。パッチを適用して2.4.3に戻ると、失敗していたフィルターを引き出すことができました： link 。

報告された原因は、今あるENOMEMの代わりにEINVAL Iの推測はことを考えると予想され、 _gen_bpf_build_bpf失敗し、返しているNULLプログラムを。 ただし、PFCは正常に印刷されます。 _gen_bpf_build_bpfの戻り値を報告するようにseccompコードを変更すると、原因としてEFAULTれます。

迅速なハックとして、私は走った:%s/return -EFAULT/abort()以上src/gen_bpf.c 、このスタックトレースを抽出することができました：

(gdb) bt full
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
        set = {__val = {0, 140084028365964, 140083248439464, 140083248438968, 140083248431088, 140084028368143, 28659884033, 140083965300736, 
            140083248439464, 140083248438968, 140083248431088, 140084028351031, 140084019988760, 140083248439624, 140083248431200, 140084028372597}}
        pid = <optimized out>
        tid = <optimized out>
        ret = <optimized out>
#1  0x00007f67daa4d55b in __GI_abort () at abort.c:79
        save_stage = 1
        act = {__sigaction_handler = {sa_handler = 0x7f67d6f3eec0, sa_sigaction = 0x7f67d6f3eec0}, sa_mask = {__val = {140083965300736, 
              140083965300736, 0, 0, 140083248438968, 140083248438968, 140083248439464, 140083248431504, 140084028417173, 140083964793344, 
              140083965300736, 140083248431552, 140083994791895, 140083248431552, 140083994787642, 140083965300736}}, sa_flags = -1404894496, 
          sa_restorer = 0x0}
        sigs = {__val = {32, 0 <repeats 15 times>}}
#2  0x00007f67d8bfd455 in _gen_bpf_build_bpf (state=0x7f67ac4302e0, col=0x7f67d6f63040) at gen_bpf.c:1943
        rc = 0
        iter = 1
        h_val = 1425818561
        res_cnt = 0
        jmp_len = 0
        arch_x86_64 = 0
        arch_x32 = -1
        instr = {op = 32, jt = {tgt = {imm_j = 0 '\000', imm_k = 0, hash = 0, db = 0x0, blk = 0x0, nxt = 0}, type = TGT_NONE}, jf = {tgt = {
              imm_j = 0 '\000', imm_k = 0, hash = 0, db = 0x0, blk = 0x0, nxt = 0}, type = TGT_NONE}, k = {tgt = {imm_j = 4 '\004', imm_k = 4, 
              hash = 4, db = 0x4, blk = 0x4, nxt = 4}, type = TGT_K}}
        i_iter = 0x7f67d6fdcb60
        b_badarch = 0x7f67d6fd9000
        b_default = 0x7f67d6fd9060
        b_head = 0x7f67d6fda1a0
        b_tail = 0x7f67d6fd9000
        b_iter = 0x0
        b_new = 0x7f67d6fe3300
        b_jmp = 0x0
        db_secondary = 0x0
        pseudo_arch = {token = 0, token_bpf = 0, size = ARCH_SIZE_UNSPEC, endian = ARCH_ENDIAN_LITTLE, syscall_resolve_name = 0x0, 
          syscall_resolve_num = 0x0, syscall_rewrite = 0x0, rule_add = 0x0}
#3  0x00007f67d8bfd560 in gen_bpf_generate (col=0x7f67d6f63040) at gen_bpf.c:1971
        rc = 0
        state = {htbl = {0x0 <repeats 256 times>}, attr = 0x7f67d6f63044, bad_arch_hsh = 889798935, def_hsh = 742199527, arch = 0x7f67ac4301e0, 
          bpf = 0x7f67d6f64010}
        prgm = 0x7f67d6f64010
#4  0x00007f67d8bf64a7 in sys_filter_load (col=0x7f67d6f63040) at system.c:265
        rc = 32615
        prgm = 0x0
#5  0x00007f67d8bf4f10 in seccomp_load (ctx=0x7f67d6f63040) at api.c:287
        col = 0x7f67d6f63040

これは1943行に対応しています。

https://github.com/seccomp/libseccomp/blob/1dde9d94e0848e12da20602ca38032b91d521427/src/gen_bpf.c#L1935 -L1943

置換の性質を考えると、ヘルパー関数のEFAULTは最初に中止されるため、除外できると思います。

この後、HEADで同じものを再現してみましたが、それでも発生します。 次に、 %s:/goto build_bpf_free_blks/abort()を繰り返します。 原因は次のとおりです。

https://github.com/seccomp/libseccomp/blob/34bf78abc9567b66c72dbe67e7f243072162a25f/src/gen_bpf.c#L2219 -L2220

ありがたいことに、この関数は短く、障害点はほんの一握りでした。 後でabort挿入の別のラウンド。

(gdb) bt full
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
        set = {__val = {0, 140050183343588, 0, 448, 140049402494880, 140049402509040, 140049402494832, 140050183342988, 140049402495088, 
            140049402509040, 140049402494896, 140050183343588, 4294967296, 140049402509040, 140049402509040, 140049402509040}}
        pid = <optimized out>
        tid = <optimized out>
        ret = <optimized out>
#1  0x00007f5ff953055b in __GI_abort () at abort.c:79
        save_stage = 1
        act = {__sigaction_handler = {sa_handler = 0x7f5ff595d260, sa_sigaction = 0x7f5ff595d260}, sa_mask = {__val = {139642271694862, 
              140050119389792, 0, 0, 140049402502840, 0, 140049402503336, 140049402502888, 140049402502840, 112, 384, 140049402502840, 140050149861504, 
              140049402495328, 140050149857273, 392}}, sa_flags = 448, sa_restorer = 0x7f5ff595d240}
        sigs = {__val = {32, 0 <repeats 15 times>}}
#2  0x00007f5ff76edee5 in _bpf_append_blk (prg=0x7f5ff5964010, blk=0x7f5ff59df1a0) at gen_bpf.c:452
        rc = -12
        i_new = 0x0
        i_iter = 0x7f5ff59fa178
        old_cnt = 48
        iter = 1
#3  0x00007f5ff76f3716 in _gen_bpf_build_bpf (state=0x7f5fcae302d0, col=0x7f5ff59c5000) at gen_bpf.c:2223
        rc = 0
        iter = 1
        h_val = 1425818561
        res_cnt = 0
        jmp_len = 0
        arch_x86_64 = 0
        arch_x32 = -1
        instr = {op = 32, jt = {tgt = {imm_j = 0 '\000', imm_k = 0, hash = 0, db = 0x0, blk = 0x0, nxt = 0}, type = TGT_NONE}, jf = {tgt = {
              imm_j = 0 '\000', imm_k = 0, hash = 0, db = 0x0, blk = 0x0, nxt = 0}, type = TGT_NONE}, k = {tgt = {imm_j = 4 '\004', imm_k = 4, 
              hash = 4, db = 0x4, blk = 0x4, nxt = 4}, type = TGT_K}}
        i_iter = 0x7f5ff59e1b60
        b_badarch = 0x7f5ff59de000
        b_default = 0x7f5ff59de060
        b_head = 0x7f5ff59df1a0
        b_tail = 0x7f5ff59de000
        b_iter = 0x7f5ff59df1a0
        b_new = 0x7f5ff59e8300
        b_jmp = 0x7f5ff59df0e0
        db_secondary = 0x0
        pseudo_arch = {token = 0, token_bpf = 0, size = ARCH_SIZE_UNSPEC, endian = ARCH_ENDIAN_LITTLE, syscall_resolve_name = 0x0, 
          syscall_resolve_num = 0x0, syscall_rewrite = 0x0, rule_add = 0x0}
#4  0x00007f5ff76f3874 in gen_bpf_generate (col=0x7f5ff59c5000, prgm_ptr=0x7f5fcae30b40) at gen_bpf.c:2270
        rc = 0
        state = {htbl = {0x0, 0x7f5ff593ef80, 0x7f5ff593efe0, 0x7f5ff593efc0, 0x0, 0x7f5ff595d000, 0x7f5ff593ef60, 0x7f5ff593ef00, 
            0x0 <repeats 248 times>}, attr = 0x7f5ff59c5004, bad_arch_hsh = 889798935, def_hsh = 742199527, bpf = 0x7f5ff5964010, 
          arch = 0x7f5fcae301c0, b_head = 0x7f5ff59e8300, b_tail = 0x7f5ff59de120, b_new = 0x7f5ff59e8300}
        prgm = <optimized out>
#5  0x00007f5ff76eb275 in sys_filter_load (col=0x7f5ff59c5000, rawrc=false) at system.c:307
        rc = 0
        prgm = 0x0
#6  0x00007f5ff76e9505 in seccomp_load (ctx=0x7f5ff59c5000) at api.c:386
        col = 0x7f5ff59c5000
        rawrc = false

https://github.com/seccomp/libseccomp/blob/34bf78abc9567b66c72dbe67e7f243072162a25f/src/gen_bpf.c#L449 -L452

それはですので、 realloc再び失敗、および_bpf_append_blk戻っている-ENOMEMでマスクされますその_gen_bpf_build_bpfと化し-EFAULT 。 これは大したことではありませんが、より良いエラー報告は2.5の目標であるとおっしゃっていたので、これは範囲内にあるように見えるので、言及したいと思います：slightly_smiling_face：

GDBをいじくりまわす：

(gdb) f 2
#2  0x00007f5ff76edee5 in _bpf_append_blk (prg=0x7f5ff5964010, blk=0x7f5ff59df1a0) at gen_bpf.c:452
452         abort();
(gdb) info args
prg = 0x7f5ff5964010
blk = 0x7f5ff59df1a0
(gdb) print prg->blks
$4 = (bpf_instr_raw *) 0x7f5ff59fa000
(gdb) x/32bx &prg->blks
0x7f5ff5964018: 0x00    0xa0    0x9f    0xf5    0x5f    0x7f    0x00    0x00
0x7f5ff5964020: 0x5a    0x5a    0x5a    0x5a    0x5a    0x5a    0x5a    0x5a
0x7f5ff5964028: 0x5a    0x5a    0x5a    0x5a    0x5a    0x5a    0x5a    0x5a
0x7f5ff5964030: 0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
(gdb) print ((prg)->blk_cnt * sizeof(*((prg)->blks)))
$5 = 392
(gdb) print prg->blk_cnt
$6 = 49

これは本当にアロケータの失敗のように見え始めます...

ああ、この話はついにその_スリリングな_結論に達しました—何が起こっているのかを理解し、修正を検証しました：slightly_smiling_face：

それは面白い話になるかもしれないので、ここにあります：

ワーカーをフォークオフする主なプロセスは、通常、最大80MBのRSSにあります。 フォークした後、 rlimitを介してメモリ使用量を64MBに制限します。 これにより、現在のメモリ使用量が制限を超える位置に配置されますが、これはrlimit許可されています。 ほとんどの場合、メモリアロケータには、カーネルからの追加要求なしにlibseccompの初期化ルーチンを処理するのに十分な空きメモリがあります。 しかし、それが_しない_場合、追加のアリーナなどのためにスペースを要求する必要がある場合、プロセスはすでに制限を超えているため、カーネルはそれを提供しません。

2.4.3では、このメモリ取得の失敗はEINVALとダブルフリーで現れました。 マスターポスト-https ：//github.com/seccomp/libseccomp/commit/3a1d1c977065f204b96293cccfe7d3e5aa0d7aceでは、代わりにEFAULTが報告されます。 https://github.com/seccomp/libseccomp/pull/257を適用すると、 ENOMEMが正しく報告されます。

これがめったに起こらない理由は、その後明らかになります。それは、カーネルに追加を要求せずにBPFプログラムを構築するのに十分なメモリがアロケータにあるかどうかに完全に依存しています。 glibcのアロケータは、断片化の蓄積を許可することについてより緩いので、これが適切な場所で発生することはありませんでした。 jemallocはより厳しい境界を設定し、 seccomp_load間にメモリを要求する必要がある可能性を高めます—結果として生じる障害に気付くのに十分ですが、それでも追跡するのは腹立たしいです。

したがって、修正は、すべてのsetrlimit呼び出しを_after_ seccomp_loadです。 そうすることで、 reallocが_bpf_append_blkで失敗しなくなり、フィルターが正常にロードされます。 これは、フィルターがsetrlimitを許可する必要があることを意味しますが、私の場合はこれで問題ありませんhttps://github.com/seccomp/libseccomp/issues/123のようなもので解決されると思い

@ pcmoore 、 @ drakenclimber-この問題のデバッグにご協力いただきありがとう

このバグは、コミットhttps://github.com/seccomp/libseccomp/commit/c0a6e6fd15f74c429a0b74e0dfd4de5a29aabebdによって修正されました