Libseccomp: RFE: 더 정확하게 정의된 오류 반환 값

@topimiettinen 님 , 죄송합니다. 이 문제를 해결하는 데 너무 오래 걸렸지만 이제 이 문제를 고칠 때가 된 것 같습니다.

@drakenclimber 이것은 바보가 될 것입니다. 모든 libseccomp API에는 이 시점에서 맨페이지가 있어야 하며(필요하지 않은 경우 이에 대한 문제를 생성할 필요가 있음) 모든 맨페이지에는 RETURN VALUE 섹션에 손으로 물결 모양의 "오류 시 음수 값" 주석이 있습니다. 다음을 수행해야 한다고 생각합니다.

• 가능한 반환 값 목록을 생성하기 위해 각 API 호출을 수동으로 감사
• 이러한 반환 값이 의미가 있는지 결정하고 그렇지 않은 경우 코드를 수정합니다.
• 오류 코드가 나타내는 내용에 대한 간략한 설명과 함께 관련 맨페이지에서 가능한 각 반환 값을 문서화합니다.

생각?

@topimiettinen 님 , 죄송합니다. 이 문제를 해결하는 데 너무 오래 걸렸지만 이제 이 문제를 고칠 때가 된 것 같습니다.

@drakenclimber 이것은 바보가 될 것입니다. 모든 libseccomp API에는 이 시점에서 맨페이지가 있어야 하며(필요하지 않은 경우 이에 대한 문제를 생성할 필요가 있음) 모든 맨페이지에는 RETURN VALUE 섹션에 손으로 물결 모양의 "오류 시 음수 값" 주석이 있습니다. 다음을 수행해야 한다고 생각합니다.

* manually audit each API call to generate a list of possible return values

* decide if these return values make sense, modify the code if they don't

* document each possible return value in the associated manpage with a brief explanation of what the error code indicates

생각?

댕.... 위에서 쓴 모든 것, 특히 필요한 노력에 마지못해 동의합니다. :). 반환 코드를 올바르게 얻은 다음 문서화하는 것은 정말 큰 노력이 될 것입니다.

그리고 네, 화려한 작업은 아니지만 중요하다고 생각합니다. 저는 일부 cgroup 관련 작업을 하고 있으며 최근에 cgroup 기능을 완전히 오해하는 컨테이너 구현을 발견했습니다... 그러나 커널이나 다른 곳에서 제대로 길을 안내할 확실한 문서가 없었기 때문에 최선을 다해 작동하게 했습니다. 그들은 할 수 있었다.

이 문제에 대한 활동을 보는 것이 좋습니다! 철저한 검토를 반대하는 것은 아니지만 원래 요청은 서로 다른 실패 모드를 구별할 수 있도록 제한되어 있었고 이는 다소 직교했습니다. 검토는 확실히 도움이 될 것입니다. 제 생각에 어느 정도 전제 조건이 있습니다.

이 문제에 대한 활동을 보는 것이 좋습니다! 철저한 검토를 반대하는 것은 아니지만 원래 요청은 서로 다른 실패 모드를 구별할 수 있도록 제한되어 있었고 이는 다소 직교했습니다. 검토는 확실히 도움이 될 것입니다. 제 생각에 어느 정도 전제 조건이 있습니다.

우리는 어느 시점에서 검토를 해야 하고, 지금 그렇게 할 수도 있습니다. 보류할수록 오류 코드는 호출자에게 덜 유용하게 되고 libseccomp의 요점은 이 항목을 사용하기 쉽게 만드는 것입니다. :)

댕.... 위에서 쓴 모든 것, 특히 필요한 노력에 마지못해 동의합니다. :). 반환 코드를 올바르게 얻은 다음 문서화하는 것은 정말 큰 노력이 될 것입니다.

네, 이것이 이 문제가 오랫동안 미뤄온 이유 중 하나지만 저는 충분히 오랫동안 미루고 있습니다(적어도 @drakenclimber 는 그가 1년 미만으로 미루고 있다고 말할 수 있습니다!). 오늘 나중에(내일?) 나는 이것을 덩어리/다중 문제(몇 가지 제안 포함)로 쪼개어 좀 더 쉽게 조각으로 다룰 것입니다.

약간의 긍정적인 점은 libseccomp가 실제로 9개의 고유한 errno 값만 사용하는 것처럼 보입니다(매우 조잡한 검사에 따르면).

# grep -e "-E[A-Z0-9]\+" src/*.{h,c} | sed 's/.*-\(E[A-Z0-9]\+\).*/\1/' | sort -u
EACCES
EDOM
EEXIST
EFAULT
EINVAL
ENOMEM
EOPNOTSUPP
EPERM
ESRCH

... 이것은 특히 라이브러리 전체에서 각 오류 코드에 대한 공통 의미 값에 동의할 수 있는 경우 문제 공간을 약간 줄이는 데 도움이 됩니다(확실히 해야 함).

이것은 의도한 것보다 약간 늦지만 libseccomp API를 구성하는 전체 함수 목록은 다음과 같습니다.

const struct scmp_version *seccomp_version(void)
unsigned int seccomp_api_get(void)
int seccomp_api_set(unsigned int level)
scmp_filter_ctx seccomp_init(uint32_t def_action)
int seccomp_reset(scmp_filter_ctx ctx, uint32_t def_action)
void seccomp_release(scmp_filter_ctx ctx)
int seccomp_merge(scmp_filter_ctx ctx_dst, scmp_filter_ctx ctx_src)
uint32_t seccomp_arch_resolve_name(const char *arch_name)
uint32_t seccomp_arch_native(void)
int seccomp_arch_exist(const scmp_filter_ctx ctx, uint32_t arch_token)
int seccomp_arch_add(scmp_filter_ctx ctx, uint32_t arch_token)
int seccomp_arch_remove(scmp_filter_ctx ctx, uint32_t arch_token)
int seccomp_load(const scmp_filter_ctx ctx)
int seccomp_attr_get(const scmp_filter_ctx ctx, enum scmp_filter_attr attr, uint32_t *value)
int seccomp_attr_set(scmp_filter_ctx ctx, enum scmp_filter_attr attr, uint32_t value)
char *seccomp_syscall_resolve_num_arch(uint32_t arch_token, int num)
int seccomp_syscall_resolve_name_arch(uint32_t arch_token, const char *name)
int seccomp_syscall_resolve_name_rewrite(uint32_t arch_token, const char *name)
int seccomp_syscall_resolve_name(const char *name)
int seccomp_syscall_priority(scmp_filter_ctx ctx, int syscall, uint8_t priority)
int seccomp_rule_add_array(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, const struct scmp_arg_cmp *arg_array)
int seccomp_rule_add(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, ...)
int seccomp_rule_add_exact_array(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, const struct scmp_arg_cmp *arg_array)
int seccomp_rule_add_exact(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, ...)
int seccomp_notify_alloc(struct seccomp_notif **req, struct seccomp_notif_resp **resp)
void seccomp_notify_free(struct seccomp_notif *req, struct seccomp_notif_resp *resp)
int seccomp_notify_receive(int fd, struct seccomp_notif *req)
int seccomp_notify_respond(int fd, struct seccomp_notif_resp *resp)
int seccomp_notify_id_valid(int fd, uint64_t id)
int seccomp_notify_fd(const scmp_filter_ctx ctx)
int seccomp_export_pfc(const scmp_filter_ctx ctx, int fd)
int seccomp_export_bpf(const scmp_filter_ctx ctx, int fd)

... 이 함수들 중에서 "int"를 반환하는 함수에 대해서만 걱정하면 됩니다.

유사한 코드 경로 및 반환 값을 가져야 하는 함수의 가능한 그룹화.

• 그룹 A

int seccomp_arch_exist(const scmp_filter_ctx ctx, uint32_t arch_token)
int seccomp_arch_add(scmp_filter_ctx ctx, uint32_t arch_token)
int seccomp_arch_remove(scmp_filter_ctx ctx, uint32_t arch_token)

• 그룹 B

int seccomp_attr_get(const scmp_filter_ctx ctx, enum scmp_filter_attr attr, uint32_t *value)
int seccomp_attr_set(scmp_filter_ctx ctx, enum scmp_filter_attr attr, uint32_t value)

• 그룹 C

int seccomp_syscall_resolve_name_arch(uint32_t arch_token, const char *name)
int seccomp_syscall_resolve_name_rewrite(uint32_t arch_token, const char *name)
int seccomp_syscall_resolve_name(const char *name)

• 그룹 D

int seccomp_rule_add_array(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, const struct scmp_arg_cmp *arg_array)
int seccomp_rule_add(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, ...)
int seccomp_rule_add_exact_array(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, const struct scmp_arg_cmp *arg_array)
int seccomp_rule_add_exact(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, ...)

• 그룹 E

int seccomp_notify_receive(int fd, struct seccomp_notif *req)
int seccomp_notify_respond(int fd, struct seccomp_notif_resp *resp)
int seccomp_notify_id_valid(int fd, uint64_t id)
int seccomp_notify_fd(const scmp_filter_ctx ctx)

• 그룹 F

int seccomp_load(const scmp_filter_ctx ctx)
int seccomp_export_bpf(const scmp_filter_ctx ctx, int fd)

... 함수가 위의 그룹 중 하나에 없으면 코드 경로 및/또는 반환 값이 고유할 수 있습니다.

그룹 C는 __NR_SCMP_ERROR만 반환합니다.

그룹 D는 EINVAL, EPERM, EOPNOTSUPP, ENOMEM, EDOM, EFAULT, EEXIST 중 하나를 반환할 수 있습니다.

seccomp_load()는 EINVAL, ENOMEM, ESRCH 및 prctl()(PR_SET_NO_NEW_PRIVS 및 PR_SET_SECCOMP의 경우 EACCES, EFAULT, EINVAL만 해당) 및 seccomp()(EACCES, EFAULT, EINVAL에 대한 매뉴얼), EINVAL에 대한 EINVAL의 errno 값을 반환할 수 있습니다. 페이지.

libseccomp가 syscall 오류를 호출자에게 다시 전달하는 경우(예: prctl() 및 seccomp(), libseccomp가 영향을 받지 않도록 단일 errno 값(아마도 ENOSYS?) 뒤에 해당 오류를 숨겨야 한다고 생각합니다 커널의 모든 변경 사항(또는 ABI 차이).

이것이 디버깅에 문제가 되면 errno 값을 호출자에게 직접 다시 전달하는 새로운 속성을 도입할 수 있습니다.

가능하지만 libseccomp 사용자가 이미 특정 errno 값을 기대하고 있는 경우 ABI/API 손상이 없는지 확인하는 것이 좋습니다. 원래 문제는 일부 시스템 호출이 일부 아키텍처(예 ugetrlimit x86_32에만 있음)에만 존재하지만 이것이 잘못 입력된 시스템 호출 이름과 구별할 수 없으므로 다른(아마도 합성) 오류 코드가 필요하다는 것입니다. .

글쎄, 우리가 이전에 말했듯이, 우리는 현재 특정 errno 값을 실제로 보장하지 않고 "실패 시 음수 값"만 보장하므로 현재 특정 errno 값에 대해 가정하고 있는 사용자를 깨는 것은 불행한 일이지만 나는 상황을 변경한다고 생각합니다. 향후 커널 버전과 ABI 전반에 걸쳐 강력한 errno 보장을 제공하는 것은 가치 있는 절충안입니다.

글쎄, 우리가 이전에 말했듯이, 우리는 현재 특정 errno 값을 실제로 보장하지 않고 "실패 시 음수 값"만 보장하므로 현재 특정 errno 값에 대해 가정하고 있는 사용자를 깨는 것은 불행한 일이지만 나는 상황을 변경한다고 생각합니다. 향후 커널 버전과 ABI 전반에 걸쳐 강력한 errno 보장을 제공하는 것은 가치 있는 절충안입니다.

동의한다.

이 평가가 완료되고 실패 시 errno 값을 업데이트하면 반환된 errno 값에 대한 일종의 보증을 만드는 것이 더 편할 것입니다.

그룹화 아이디어가 최선이 아닐 수 있으므로 이 모든 것을 추적하기 위해 목록을 시작하겠습니다 _(진행하면서 계속 업데이트하겠습니다)_:

• [x] seccomp_reset
  현재 반환: EINVAL, ENOMEM.

• [x] seccomp_merge
  현재 반환되는 항목: EINVAL, EDOM, EEXIST, ENOMEM.

• [x] seccomp_arch_exist
  현재 반환: EINVAL, EEXIST.

• [x] seccomp_arch_add
  현재 반환: EINVAL, EEXIST, ENOMEM, EDOM.

• [x] seccomp_arch_remove
  현재 반환: EINVAL, EEXIST.

• [x] seccomp_load
  현재 반환되는 항목: EINVAL, ENOMEM, ESRCH, ECANCELED.

• [x] seccomp_attr_get
  현재 반환: EINVAL, EEXIST.

• [x] seccomp_attr_set
  현재 반환: EINVAL, EACCES, EOPNOTSUPP, EEXIST.

• [x] seccomp_syscall_resolve_name_arch
  이미 잘 정의되어 있으며 실패 시 시스템 호출 값 또는 __NR_SCMP_ERROR를 반환합니다.

• [x] seccomp_syscall_resolve_name_rewrite
  이미 잘 정의되어 있으며 실패 시 시스템 호출 값 또는 __NR_SCMP_ERROR를 반환합니다.

• [x] seccomp_syscall_resolve_name
  이미 잘 정의되어 있으며 실패 시 시스템 호출 값 또는 __NR_SCMP_ERROR를 반환합니다.

• [x] seccomp_syscall_priority
  현재 반환: EINVAL, EDOM, EFAULT, ENOMEM.

• [x] seccomp_rule_add_array
  현재 반환되는 항목: EINVAL, EOPNOTSUPP, ENOMEM, EDOM, EFAULT, EEXIST.

• [x] seccomp_rule_add
  현재 반환되는 항목: EINVAL, EOPNOTSUPP, ENOMEM, EDOM, EFAULT, EEXIST.

• [x] seccomp_rule_add_exact_array
  현재 반환되는 항목: EINVAL, EOPNOTSUPP, ENOMEM, EDOM, EFAULT, EEXIST.

• [x] seccomp_rule_add_exact
  현재 반환되는 항목: EINVAL, EOPNOTSUPP, ENOMEM, EDOM, EFAULT, EEXIST.

• [x] seccomp_notify_alloc
  현재 반환되는 항목: EOPNOTSUPP, ENOMEM, EFAULT, ECANCELED. 맨페이지는 이미 오류 발생 시 -1을 지정하고 있으며 이는 seccomp() errno만 참조할 수 있습니다.

• [x] seccomp_notify_receive
  현재 반환되는 항목: EOPNOTSUPP 및 ECANCELED. 맨페이지는 이미 오류 발생 시 -1을 지정하고 있으며 이는 seccomp() errno만 참조할 수 있습니다.

• [x] seccomp_notify_respond
  현재 반환되는 항목: EOPNOTSUPP 및 ECANCELED. 맨페이지는 이미 오류 발생 시 -1을 지정하고 있으며 이는 seccomp() errno만 참조할 수 있습니다.

• [x] seccomp_notify_id_valid
  현재 반환되는 항목: EOPNOTSUPP 및 ECANCELED. 맨페이지는 이미 seccomp() errno만 참조하는 오류(잘못된 ID) 시 -ENOENT를 지정합니다.

• [x] seccomp_notify_fd
  이미 잘 정의되어 있으며 알림 fd를 반환합니다.

• [x] seccomp_export_pfc
  현재 반환: EINVAL 및 ECANCELED.

• [x] seccomp_export_bpf
  현재 반환되는 항목: EINVAL, ENOMEM 및 ECANCELED.

이제 우리는 어떤 함수가 어떤 오류 코드를 반환하는지에 대한 목록을 가지고 있으므로 특히 우리가 이미 오류 코드를 사용하는 방법과 상당히 일치하기 때문에 이에 대해 조금 더 기분이 좋습니다. 마지막 비트가 큰 도움이 될 것입니다.

수정 사항을 수집하고 변경 사항에 대한 피드백을 수집할 수 있도록 PR을 시작하겠습니다. 곧 여기에 게시하겠습니다.

ENOSYS의 다소 "특별한" 특성을 감안할 때 errno를 커널/libc catch-all로 사용하는 것에 대해 유보하고 있습니다. 다른 값을 살펴봐야 합니다. 이에 대해 강한 느낌/생각이 있는 사람이 있습니까?

아직 많이 빠져있고 대부분 맨페이지 편집과 코드 주석(테스트는 말할 것도 없음)이 있지만 다음 분기를 보면 제가 생각하는 바를 알 수 있습니다.

• https://github.com/pcmoore/misc-libseccomp/tree/working-rc

ENOSYS의 다소 "특별한" 특성을 감안할 때 errno를 커널/libc catch-all로 사용하는 것에 대해 유보하고 있습니다. 다른 값을 살펴봐야 합니다. 이에 대해 강한 느낌/생각이 있는 사람이 있습니까?

EIO는 어떻습니까?

EIO는 어떻습니까?

그것이 오류를 훨씬 더 실행 가능하게 만들지 모르겠습니다. 대신 errno 값을 사용하지 않는 함수로 API를 확장하는 것은 어떻습니까? 하지만 예를 들면 다음과 같습니다.

• SCMP_ERROR_UNKNOWN_SYSCALL: 시스템 호출이 libseccomp에 의해 알려져 있지 않음: 호출자는 이것을 사용하여 사용자 입력을 거부할 수 있습니다(예: 시스템 호출 이름의 오타).
• SCMP_ERROR_SYSCALL_NOT_FOR_THIS_ARCH: 시스템 호출은 libseccomp에 의해 알려져 있지만 여기서는 사용할 수 없습니다. 호출자는 이 아키텍처에 대해서만 이 오류를 무시할 수 있습니다.
• SCMP_ERROR_API_USAGE: libseccomp는 올바르게 작성된 코드에서 발생해서는 안 되는 호출 논리 문제를 감지했습니다. 호출자가 assert()를 트리거할 수 있음
• SCMP_ERROR_KERNEL_OTHER: libseccomp는 입력과 호출 순서에 문제가 없었지만 커널은 ENOMEM, EPERM, ENOSYS와 같이 잘 정의된 특정 오류를 반환했습니다. 호출자는 조치를 위해 errno를 확인해야 합니다. libseccomp가 오류의 원인이 호출자에 의한 오류(예: EFAULT)로 인해 발생하는 것으로 알려진 경우 SCMP_ERROR_API_USAGE를 대신 사용할 수 있습니다.
• SCMP_ERROR_KERNEL_API_USAGE: libseccomp는 입력 등으로 괜찮았지만 커널은 명확하지 않고 명백한 이유로 그것을 좋아하지 않았습니다. 이것은 커널 변경, 비활성화된 구성, libseccomp 또는 호출자의 버그, 매우 이상한 사용자 입력 등을 나타낼 수 있습니다. 호출자를 위한 조치는 이벤트 및 오류를 기록하고 개발자(호출자 및/또는 libseccomp)에게 정보를 전달하라는 요청을 포함할 수 있습니다. 추가 분석, assert() 가능하지 않습니다.

또는 errno가 있는 API는 그대로 유지될 수 있지만 새 함수를 사용하여 위의 오류 코드를 요청할 수 있습니다.

아마도 @poettering 또는 @keszybz 도 댓글을 달 수 있습니다.

그것이 오류를 훨씬 더 실행 가능하게 만들지 모르겠습니다. 대신 errno 값을 사용하지 않는 함수로 API를 확장하는 것은 어떻습니까?

글쎄, 우리가 그런 일을 하는 것을 고려하기 전에(그리고 우리가 그렇게 하고 싶은지 확신이 서지 않는다) 우리는 안정적이고 지원되는 반환 코드에 정착해야 합니다. 이것이 우리가 여기서 작업하고 v2.5에서 목표로 하는 것입니다.

v2.5에서 안정적/지원되는 반환 코드를 가져오고 어떻게 진행되는지 확인할 수 있습니다. 추가 작업이 필요한 경우 v2.6에 대해 고려할 수 있습니다.

EIO는 어떻습니까?

다른 작업 우선 순위와 일부 커널 문제로 인해 잠시 이 작업을 중단했지만 이제 libseccomp로 돌아와서 여기서 EIO를 사용하는 것이 잘못된 것 같다는 것을 깨닫고 있습니다. 이에 대해 조금 더 생각해 보겠습니다.

포괄적인 커널 오류 코드인 ECANCELED는 어떻습니까?

@drakenclimber 어떻게 생각하시는지 궁금합니다.

다른 작업 우선 순위와 일부 커널 문제로 인해 잠시 이 작업을 중단했지만 이제 libseccomp로 돌아와서 여기서 EIO를 사용하는 것이 잘못된 것 같다는 것을 깨닫고 있습니다. 이에 대해 조금 더 생각해 보겠습니다.

여기도 마찬가지입니다. 최근에 상황이 조금 바빴습니다./.

@drakenclimber 어떻게 생각하시는지 궁금합니다.

확신하는. 전체 스레드를 다시 읽고 싶습니다.

포괄적인 커널 오류 코드인 ECANCELED는 어떻습니까?

나는 ECANCELED에 대해 별로 익숙하지 않다는 것을 인정합니다. 커널 소스에서 사용법을 간단히 살펴보고 구글 검색도 했습니다. ECANCELED는 이전 libseccomp, prctl() 또는 우리가 사용한 다른 API와 충돌이 없으며 커널이 우리에게 던지는 모든 오류를 합리적으로 캡슐화할 수 있다고 생각합니다.

tl;dr - 커널 오류에 대한 포괄적인 솔루션으로 ECANCELED를 사용하는 것이 좋습니다.

감사합니다. 반쯤 구운 패치 세트가 있습니다. 마무리하고 검토를 위해 PR로 제출할 것입니다.