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 를 추가해도 차이가 없습니다(현학적 오류 처리, btw를 사용하면 100줄 미만).

좋아요, 그냥 언급하고 싶었습니다. 당신이 일을 올바르게하고있는 것처럼 들립니다 (새 스레드를 생성하기 전에 필터를 설정하십시오). 좀 더 지켜봐야 하겠지만, 조만간 그럴 기회가 없을 것 같습니다.

내가 뻔뻔하게 잘못된 일을 하고 있지 않다는 확인만으로도 충분합니다. 천천히하세요!

단일 스레드 예제 ./seccomp_omp -t 1 -k 0 에서 openmp는 단일 스레드만 실행될 것임을 인식하므로 openmp는 다중 스레드 for 루프에서 일반적으로 수행하는 동기화의 대부분을 우회합니다. 커널의 seccomp_run_filters()에서 처리된 시스템 호출을 관찰하여 이를 확인했습니다. 예상대로 __NR_write()에 대한 호출과 seccomp가 스레드를 종료하도록 커널에 지시하도록 유도하는 __NR_madvise()에 대한 호출을 보았습니다.

다중 스레드 예제 ./seccomp_omp -t 2 -k 0 에서 openmp는 for 루프를 병렬화하려고 시도합니다. 따라서 훨씬 더 많은 openmp 라이브러리가 활용됩니다. 이것은 seccomp_run_filters()를 통해 시스템 호출을 다시 볼 때 분명합니다. __NR_mmap(), __NR_mprotect(), __NR_clone(), __NR_futex() 및 더 많은 시스템 호출이 madvise()를 호출하기 전에 호출됩니다. 궁극적으로 두 스레드 중 하나가 마침내 madvise()를 호출하고 seccomp가 해당 스레드를 적절하게 종료합니다. 그러나 openmp는 스레드 사이에 동기화를 가지고 있으며 두 번째 스레드가 madvise()를 호출하기 전에(그리고 죽기 전에) 두 번째 스레드는 죽은 스레드에서 무언가를 기다리고 있을 때 futex()를 호출합니다. 그리고 이것이 프로그램이 중단되는 이유입니다. 하나의 스레드가 종료되었고 두 번째 스레드는 도착하지 않을 데이터(죽은 스레드에서)를 기다리고 있습니다.

나는 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 ? 모든 syscall에서 잘 작동하는 것이 있습니까?

@pcmoore - 좀. 그러나 더 큰 문제는 openmp가 병렬 구조 내에서 신호를 정상적으로 처리하지 않는다는 것입니다. 나는 이것이 디자인에 의한 것이라고 생각합니다.

@kloetzl - 걱정하지 마세요. OpenMP를 완전히 고수할 수 있습니다. OpenMP 커뮤니티의 다른 사람들이 다음과 같은 일을 하고 있는 것 같습니다.

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; 
}

SCMP_ACT_ERRNO() 반환해야 하는 오류 SCMP_ACT_ERRNO() 는 모든 시스템 호출에서 작동합니다. 그리고 당신의 프로그램은 그것을 처리하고 사용자에게 오류를 반환하는 프로그램이 될 것입니다. 그래서 당신은 당신에게 가장 적합한 errno를 선택할 수 있습니다. 실제로 ENOTBLK 같이 모호한 것을 선택 하면 오류가 호출을 차단하는 seccomp에서 발생했음을

tl;dr - 병렬 루프에서 문제를 감지하지만 루프가 완료될 때까지 처리를 기다립니다. 실패한 시스템 호출로 인해 루프 내에 추가 방어 코딩을 추가해야 할 수도 있습니다.

@kloetzl - 문제 #96을 살펴보고 OpenMP와 얼마나 잘 작동하는지 확인하겠습니다. 그것은 또 다른 해결책이 될 수도 있습니다. 감사 해요!

그리고 당신의 프로그램은 그것을 처리하고 사용자에게 오류를 반환하는 프로그램이 될 것입니다. 그래서 당신은 당신에게 가장 적합한 errno를 선택할 수 있습니다. 사실, ENOTBLK와 같이 모호한 것을 선택하면 오류가 호출을 차단하는 seccomp에서 발생했다는 것을 알 수 있습니다.

문제는 madvise 가 malloc 의 깊숙한 곳에서 호출된다는 것입니다. 따라서 나는 오류를 처리하는 사람이 아닙니다. glibc는 그렇습니다. 따라서 문제는 glibc(및 시스템 호출을 수행하는 다른 모든 라이브러리)가 시스템 호출이 매뉴얼 페이지에 제공된 것과 다른 오류를 반환하고 적절하게 처리할 수 있다는 것을 알고 있습니까?

문제는 madvise가 malloc의 깊숙한 곳에서 호출된다는 것입니다. 따라서 나는 오류를 처리하는 사람이 아닙니다. glibc는 그렇습니다. 따라서 문제는 glibc(및 시스템 호출을 수행하는 다른 모든 라이브러리)가 시스템 호출이 매뉴얼 페이지에 제공된 것과 다른 오류를 반환하고 적절하게 처리할 수 있다는 것을 알고 있습니까?

아... 알았어. 확실히 하려면 glibc 코드를 살펴봐야 하지만 다음과 같은 추측에 위험을 감수할 수 있습니다.

• madvise 가 오류를 반환하면 glibc는 _확실히_ 오류도 반환합니다.
• glibc가 seccomp가 반환한 것과 다른 오류를 반환할 가능성이 있으므로 ENOTBLK 와 같은 "사용자 지정" 반환 코드를 예상하는 경우 주의해야 합니다.

간단히 말해서 glibc는 _any_ 오류 코드를 억제하지 않아야 하지만 대신 다른 오류 코드를 반환할 수 있습니다.

나는 여러분과 함께하려고 노력하고 있지만 OpenMP에 대한 배경 지식이 부족하여 약간 뒤쳐질 것 같습니다 ... 위의 의견에 따르면 KILL_PROCESS 여기에서 실행 가능한 솔루션이 될 수 있습니까? 그렇다면 v2.4 릴리스 전에 해결해야 할 사항 목록에 있지만 해당 문제의 우선 순위를 높일 수 있습니다.

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

@pcmoore - 예, KILL_PROCESS 가 이 버그에 대한 실행 가능한 솔루션이라고 생각합니다. KILL_PROCESS 작업을 사용하여 위의 @kloetzl 의 테스트 프로그램을 테스트

나는 그것을 구현했지만 현재 파이썬 자동 테스트에서 몇 가지 걸림돌을 치고 있습니다. 다음 주에 패치가 나와야 합니다.

@drakenclimber 오, 패치? 저는 패치를 좋아합니다 :)

고마워 얘들아.

KILL_PROCESS 문제가 해결되었음을 확인할 수 있습니다. 저도 Arch에서 로컬 버전의 libseccomp를 해킹했으며 테스트 프로그램이 의도한 대로 실패했습니다. 그러나 견고한 테스트를 제공하고 이를 다른 커널에서 실행하는 것이 더 큰 도전이 될 수 있습니다.

@kloetzl 확인 감사합니다.

예, 적절한 테스트를 작성하는 것은 지루할 수 있지만 중요합니다. IMHO를 테스트하는 코드만큼 중요합니다.

@drakenclimber 의 PR을 기대하고 있습니다. 해당 코드가 게시되면 좀 더 논의할 수 있습니다.

저는 COVID-19 봄철 대청소를 하고 있는데 문제가 해결된 것 같습니다. @kloetzl이 맞습니까? 이 문제를 닫을 예정이지만 내가 틀렸고 여전히 문제가 표시되면 알려주시면 다시 열겠습니다!

상기시켜 주셔서 감사합니다. 나는 약간의 테스트를 거쳤습니다.

이 문제는 대부분 해결되었으며 작은 문제가 있습니다. 잘못된 시스템 호출이 발생했을 때 프로그램이 더 이상 림보에 걸리지 않습니다. SCMP_ACT_TRAP 를 사용하면 잘못된 시스템 호출의 이름을 생성할 수도 있습니다. 그러나 OpenMP는 내 신호 처리기를 덮어쓰므로 여러 스레드가 생성되면 기본 오류 메시지로 대체됩니다. 사용자 경험의 관점에서 나는 이 동작이 마음에 들지 않지만 가능한 한 좋다고 생각합니다.

아, 예, libseccomp에서 신호 처리기를 덮어쓰는 것에 대해 우리가 할 수 있는 일이 많지 않습니다. 죄송합니다.

나머지 작업이 완료되었음을 알려주셔서 감사합니다!