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 릴리스에서 목표로 하는 개선 사항 중 하나는 문서화 및 오류 코드 처리 개선입니다.

최근에 libseccomp 2.3.3(Debian 안정 저장소 버전)에서 2.4.3으로의 업그레이드가 포함된 Docker 컨테이너의 패키지를 업그레이드했습니다. 다른 시스템 패키지도 업그레이드되었지만 기록하지 않았습니다. 우리 커널은 업그레이드되지 않았으며 버전은 4.19.0-8-amd64입니다.

코드와 기본 커널이 변경되지 않았는지 확인해주셔서 감사합니다. 문제를 추적하는 데 도움이 됩니다.

참고로 이것은 seccomp_rule_add 매뉴얼 페이지 와 유사한 오류 검사를 사용하는 seccomp 초기화 ​​루틴 전체입니다.

당신의 필터는 나에게 합리적으로 보입니다.

무엇이 잘못될 수 있는지(또는 무엇이 잘못되고 있는지 자세히 알아보는 방법), 또는 이것이 어떤 식으로든 예상되는 경우에 대한 아이디어가 있습니까? 역동적으로 움직이는 부분이 많지 않으며 문서에서 왜 이런 일이 발생할 수 있는지에 대한 내용을 찾을 수 없습니다.

v2.4.3 seccomp_load() 코드를 살펴보니 libseccomp가 -EINVAL 의 반환 코드를 생성하는 곳이 두 곳뿐인 것 같습니다.

• seccomp_load() 283행
• _gen_bpf_build_bpf() 라인 1657

위의 두 오류는 모두 유효하지 않은 필터로 인해 발생합니다. 당신의 필터 코드를 기반으로 할 것 같지 않습니다.

seccomp_set_mode_filter() 있는 커널의 기본 반환 값 은 -EINVAL 이므로 시스템의 다른 항목이 변경되어 해당 경로로 떨어질 수 있습니다. Docker에서 실행 중이라고 언급했습니다. 기본 Docker seccomp 필터를 비활성화하고 있습니까?

seccomp_load() 실패 후 if 내부의 코드에 디버깅을 더 추가하고 싶을 것입니다. 예를 들어 필터 자체의 PFC 및/또는 BPF를 출력하여 합리적으로 보이는지 확인할 수 있습니다. seccomp_export_pfc() 및 seccomp_export_bpf() .

v2.4.3 seccomp_load() 코드를 살펴보니 libseccomp가 -EINVAL 의 반환 코드를 생성하는 곳이 두 곳뿐인 것 같습니다.

• seccomp_load() 283행
• _gen_bpf_build_bpf() 라인 1657

gen_bpf_generate(...) 또는 그 이하에서 발견된 모든 실패는 src/system.c:267 에서 sys_filter_load(...) 에 의해 -ENOMEM에 효과적으로 결합됩니다.

나는 "기억 손상"으로 되돌아가는 것을 싫어한다! 너무 빠르지만 여기에서는 그럴 수 있습니다.

빠르고 자세한 답변 감사합니다! 그들은 여러 탐색 경로를 생성했습니다.slightly_smiling_face:

업그레이드 이후 프로그램에서 다른 이상한 동작을 발견하셨습니까? 다른 곳에 문제를 일으키는 메모리 손상 문제가 있는지 궁금합니다.

아니, 이것만. 우리의 단위 및 통합 테스트는 계속 통과하고 있으며 이 매우 드문 EINVAL 하고는 prod에 오류가 기록되지 않습니다. 이것은 확실히 그것을 어리둥절하게 만듭니다. 나는 또한 메모리 손상을 의심했지만 그것을 뒷받침할 증거를 찾지 못했습니다 :slightly_frowning_face:

좀 더 자세한 내용은 다음과 같습니다.

• 프로그램은 Cython을 통해 일부 C++를 호출하는 Python 앱입니다(GIL은 이 시간 동안 유지되므로 Python은 다른 스레드에 할당하지 않음)
• C++ 사이드 포크 및 자식에서 exec 전에 seccomp 필터를 설정합니다.
• post-fork, pre-exec에서 발생하는 모든 메모리 할당은 seccomp_init 등에서 libseccomp 자체에서 발생합니다.
• C++ 코드 호출과 분기 사이에 정확히 4개의 배열 malloc 이 있으며, 모두 Cython에 있으며 쓰기 시 적절한 범위가 있습니다(라인 435는 이전에 연결된 seccomp 코드를 호출함) -- 다른 모든 할당/쓰기 등. 파이썬 인터프리터 내에 있습니다

이것을 입력하는 동안 아이디어가 있었습니다. malloc 포크 후 사용하기에 안전하지 않다는 무서운 이야기를 들었고 libseccomp 자체에 몇 가지가 있습니다. Python 앱 자체는 _is_ 다중 스레드이지만 기본 코드에 있는 동안 항상 GIL을 유지하므로 안전해야 합니다(?). 하지만 malloc-after-fork를 통해 교착 상태가 발생한다는 이야기만 들었습니다. (이것이 다음 비즈니스 순서가 seccomp_init 등을 포크 전에 이동하고 seccomp_load 포스트 포크만 호출하고 오류가 계속 발생하는지 확인하는 것 같습니다.)

seccomp_load()가 실패한 후 if 내부의 코드에 디버깅을 더 추가하고 싶을 것입니다.

제안해 주셔서 감사합니다! seccomp_export_pfc 에 대한 호출을 추가하고 입력 내용을 필터( config->syscall_whitelist )에 덤프했습니다. 다음에 이것이 실패하면 후속 조치를 취하겠습니다.

안녕하세요 @Xyene - 약 일주일이

불행히도 아직 아닙니다. seccomp_export_pfc 패치를 추가한 후 침묵했습니다. 어제 저는 문제가 발생했을 때 문제를 캡처하기 위해 해당 패치를 모든 VM(단지 테스트용이 아닌)에 푸시했습니다.

나는 침묵을 이상하게 생각하지만 지금은 모든 디버깅/내보내기 논리가 seccomp_load 실패 _후_ 발생하기 때문에 우연의 일치로 생각하고 있으므로 실패 자체에 영향을 주어서는 안 됩니다.

진전!

그것이 침묵했던 이유는 seccomp_export_bpf 이 segfaulting( seccomp_load 다음에 호출된 경우 해야 합니까?)이고, 내가 seccomp 실패를 찾고 있던 곳이 아닌 다른 곳에서 보고되었기 때문입니다. 더 중요한 것은 ~150회 호출에서 문제를 안정적으로 재현할 수 있는 경우에 부딪쳤기 때문에 일부 배관 작업을 통해 일부 코어 덤프를 추출할 수 있어야 한다는 것입니다.

좋아, 나는 코어 덤프를 꺼냈고 이것이 추적이었다: https://gist.github.com/Xyene/920f1cb098784a031f53c66a2f49d167

이것은 jemalloc의 realloc 루틴 내에서 충돌하기 때문에 약간 의심스러웠습니다. 또한 glibc malloc을 대신 사용하면 문제가 해결됩니다(불행히도 조각화 문제로 인해 이 경우 장기 옵션이 아닙니다).

다음으로 jemalloc을 가져와 -O0 및 디버깅 기호로 컴파일하고 재생산을 다시 실행했습니다. 이번에는 이후가 아니라 seccomp_load 에서 충돌했습니다! 여기에 그 추적을 업로드했습니다: https://gist.github.com/Xyene/5da56168bcea337da85b2cd30704d12e

해당 추적의 스니펫:

#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 가 이미 해제된 것을 해제하려고 시도하는 코드를 충돌시키는 특정 의도 로 여유 바이트를 free로 표시하는 데 사용되는 것 같습니다.

v2.4.3의 gen_bpf.c:511 는 다음과 같습니다. https://github.com/seccomp/libseccomp/blob/1dde9d94e0848e12da20602ca38032b91d521427/src/gen_bpf.c#L505 -L513

그러나 이것은 프로그램의 수명이 sys_filter_load 의 본문일 뿐이므로 의미가 없습니다.

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

나는 적어도 하나의 문제를 발견했다고 생각합니다. 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.bpf 가 _state_release 호출 시 prgm 로 설정되어 있는 경우를 고려하면. 그러면 prgm 가 가리키는 메모리가 해제됩니다.

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

다음으로 gen_bpf_generate 는 해제되었지만 여전히 0이 아닌 포인터인 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 의 끝에서 gen_bpf_release 가 이미 비어 있는 prgm 에 대해 호출됩니다.

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!

3a1d1c977065f204b96293cccce7d3e5aa0d7ace 이상으로 이 문제를 수정해야 한다고 생각합니다. 잠시 생각해 보겠습니다... 수정이 너무 어려울 것이라고 생각하지 않습니다... 그리고 PR을 할 수 있는지 확인합니다.

3a1d1c9 이상으로 이 문제를 수정해야 한다고 생각합니다. 잠시 생각을 해보죠... 수정이 너무 어려울 것 같지는 않습니다... 그리고 PR을 할 수 있는지 확인하십시오.

이런, 나는 그것을 작성할 때 오래된 코드를 보고 있었습니다. 예, 3a1d1c9가 이 문제를 해결한다고 생각하지만 릴리스 2.4 분기에 대한 패치가 필요합니다. 이제 작업하겠습니다.

_(메타: 계속 진행하면서 이 메시지를 내 발견으로 계속 업데이트할 예정이므로 스팸 메일을 보내지 않고 기록할 수 있는 곳이 있습니다. :)_

좋아, 패치가 적용된 2.4.3으로 돌아가서 실패한 필터를 꺼낼 수 있었습니다: link .

보고 된 원인은 지금 ENOMEM 대신 EINVAL 내가 생각하는이, 주어진 예상된다 _gen_bpf_build_bpf 실패하고 반환 NULL 프로그램을. 그러나 PFC는 잘 인쇄됩니다. _gen_bpf_build_bpf 의 반환 값을 보고하도록 seccomp 코드를 수정하면 EFAULT 가 원인으로 표시됩니다.

빠른 해킹으로 :%s/return -EFAULT/abort() over 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 는 _gen_bpf_build_bpf 의해 마스킹되어 -EFAULT -ENOMEM 를 반환합니다. 이것은 큰 문제는 아니지만 더 나은 오류 보고가 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 커밋으로 수정되었습니다.