Libseccomp: 버그: seccomp_arch_add()는 엔디안 불일치 시 -EEXISTS를 반환합니다.

에 만든 2017년 06월 20일 · 18코멘트 · 출처: seccomp/libseccomp

(내 문제 설명은 golang으로 시작하지만 실제로는 C 문제입니다. 아래 참조)

나는 오늘 내 amd64 시스템에서 ScmpFilter.AddArch(seccomp.ArchPPC)를 실행하는 몇 가지 단위 테스트를 작성하고 있었습니다. 이것은 오류를 반환하지 않았지만 아키텍처가 필터에 추가되지 않았습니다(exportPFC를 통해 볼 수 있음).

다음은 간단한 재생기입니다(amd64 또는 i386에서 실행해야 함).

package main

import (
    "os"
    "github.com/seccomp/libseccomp-golang"
)

func main() {
    secFilter, err := seccomp.NewFilter(seccomp.ActKill)
    if err != nil {
        panic(err)
    }
    err = secFilter.AddArch(seccomp.ArchPPC)
    if err != nil {
        panic(err)
    }
    secFilter.ExportPFC(os.Stdout)
}

약간의 디버깅 후에 엔디안 불일치가 있는 경우 seccomp_arch_add()가 EEXIST를 반환하는 것으로 나타났습니다. db.c:db_col_db_add()에는 다음이 있습니다.

if (col->endian != 0 && col->endian != db->arch->endian)
        return -EFAULT;

golang 코드는 내가 관찰한 행동으로 이어지는 EEXIST를 (정당하게) 무시합니다.

seccomp_arch_add()가 EINVAL 같은 다른 오류 코드를 반환한다는 것이 말이 되는지 궁금합니다. 이것이 너무 위험한 경우(기존 응용 프로그램을 중단할 수 있으므로) 문서화하는 것이 좋습니다. PR을 제공하게 되어 기쁩니다.

bug prioritmedium

출처

mvo5

모든 18 댓글

신고해 주셔서 감사합니다. 자세히 살펴봐야 합니다.

pcmoore 에 2017년 06월 21일

@mvo5로 돌아오는 데 너무 오랜 시간이 걸렸다는 점을 매우 유감스럽게 생각합니다. 양해해 주셔서 감사합니다.

좀 명확히 하기 위해 현재 관련 db.c:db_col_db_add()는 다음과 같습니다.

        if (col->endian != 0 && col->endian != db->arch->endian)
                return -EEXIST;

... 원래 문제 보고서의 위 버전은 문제를 해결하기 위해 로컬로 패치된 복사본이라고 생각합니다. 즉, 여기에서 반환된 오류를 변경하는 것이 합리적으로 들립니다. 우리는 다른 아치/엔디안 코드 중 적어도 일부에서 EDOM을 사용하고 있습니다. 이것이 합리적으로 들립니까?

@mheon은 어떻게 생각하세요?

우리가 있는 동안 db.c:db_col_merge()도 업데이트해야 할 것 같습니다.

pcmoore 에 2019년 01월 15일

👍1

API의 관점에서 보면 변경하는 것이 합리적이라고 생각합니다. 오류 코드를 오버로딩하는 것은 항상 디버깅에 문제가 됩니다.

libseccomp-golang 측에서는 부정적인 ERRNO 규칙이 유지되는 한 코드 변경이 필요하지 않습니다. 새 오류가 무엇을 의미하는지 설명하기 위해 AddArch에 몇 줄의 주석을 추가하면 API 문서가 완성됩니다.

mheon 에 2019년 01월 15일

Travis는 여전히 너무 오래된 커널을 실행 중이므로 테스트 #47이 다시 실패했습니다. @pcmoore가 얼마 전에 언급했듯이 나는 이것을 피하기 위해 테스트에 약간의 영리함을 추가하려고 노력할 것입니다.

그렇지 않으면 이 변경 사항의 다른 모든 것이 내 책에서 좋아 보입니다.

drakenclimber 에 2019년 02월 04일

@drakenclimber 제 생각엔 47번이 아니라 46번 테스트를

몇 달 전에 라이브 테스트를 위한 API 레벨 검사를 추가했지만 bpf-sim 테스트에는 필요하지 않다고 생각 합니다. 그렇죠? bpf-sim 테스트 가 깔끔하게 실행되고

pcmoore 에 2019년 02월 04일

Travis는 위의 실행에 대해 테스트 #47(KILL_PROCESS)에서 확실히 토했습니다. 나는 또한 오늘 아침에 온전성 검사로 별도의 브랜치로 푸시했을 때 master의 HEAD에서 동일한 실패를 보았습니다.

테스트 47-live-kill_process%%001-00001 결과: FAILURE 47-live-kill_process 3 KILL_PROCESS rc=12

꽤 오래전에 이야기를 해서 기억이 흐릿할 수 있지만, Travis의 커널이 4.14보다 이전 버전이기 때문에 Travis가 KILL_PROCESS 테스트에 문제가 있다고 생각했습니다. 그 기능이 도입되었을 때였습니다.

아니면 내가 미쳤는지... 완전히 기억을 못하는 건가요?

drakenclimber 에 2019년 02월 05일

흠, 같은 로그를 보고 있는 건가요? 아래 빌드 및 로그를보고 있습니다.

... 다음 결과를 보여줍니다(여기서 "c" 테스트만 복사했으며 "python" 결과는 동일함).

 batch name: 46-sim-kill_process
 test mode:  c
 test type:  bpf-sim
Test 46-sim-kill_process%%001-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%002-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%003-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%004-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%005-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%006-00001 result:   ERROR 46-sim-kill_process rc=12
 batch name: 47-live-kill_process
 test mode:  c
 test type:  live
Test 47-live-kill_process%%001-00001 result:   SKIPPED (must specify live tests)

... 예, 이전 커널에는 일부 라이브 테스트에 문제가 있지만 9d4f7f69714d5af80309aa1b8a6d2c8300bb6730에서 수정되어야 합니다.

FWIW, 마스터 브랜치의 마지막 Travis 빌드가 깨끗하게 실행되었습니다.

https://travis-ci.org/seccomp/libseccomp/builds/431949896

Travis에서 모든 것이 "정상"인지 확인하기 위해 마스터 분기를 사용하여 새 빌드를 트리거했습니다.

https://travis-ci.org/seccomp/libseccomp/jobs/488759868

pcmoore 에 2019년 02월 05일

나는 지금 _정말_ 혼란스럽다는 것을 인정합니다. 귀하의 링크는 확실히 테스트 # 46이 문제임을 보여줍니다. 그러나 오른쪽 상단 모서리에 있는 "Raw Log" 링크를 클릭하면 #47이 실패했다고 알려줍니다. 위에 나열된 링크의 경우 원시 로그가 나를 리디렉션한 위치는 다음과 같습니다.

https://api.travis-ci.org/v3/job/488643923/log.txt

drakenclimber 에 2019년 02월 05일

그래서 자세히 보면 우리 둘 다 맞는 것 같아요.

46은 지적한 대로 `ERROR` 를 반환합니다. 그리고 #47은 `FAILURE` 반환합니다(이는 내가 원래 검색한 것입니다.)

그리고 이것은 요약에서도 볼 수 있습니다.

Regression Test Summary
 tests run: 14090
 tests skipped: 114
 tests passed: 14090
 tests failed: 0
 tests errored: 12

Regression Test Summary
 tests run: 16
 tests skipped: 0
 tests passed: 14
 tests failed: 2
 tests errored: 0

drakenclimber 에 2019년 02월 05일

3.x 커널로 부팅하면 내 시스템 중 하나에서 TravisCI의 문제를 재현할 수 있습니다. 테스트 46은 sys_chk_seccomp_action() 에서 문제가

나는 Test 47의 문제가 비슷하다고 상상하겠지만, 나는 그 실패 경로를 조사하지 않았다. (비록 API를 확인하기 위해 @pcmoore 변경이 추가되어 이를 방지해야 했습니다. 흠...)

Travis에서 무엇이 이 문제를 야기했는지 궁금합니다. 그들은 정말 오래된 커널로 돌아갔습니까? 우리 쪽에서 뭔가?

이것을 처리하기 위해 bpf-sim 테스트에 약간의 스마트를 추가해야 할 것 같습니다. *.tests 파일에 추가된 API 열을 모방하시겠습니까? 아니면 완전히 다른 작업을 수행하시겠습니까?

drakenclimber 에 2019년 02월 05일

예, 왜 지금은 작동하지 않는지 정말 혼란스럽습니다. 요즘 우분투 14.xx가 정말 구식이라 Travis에서 최신 버전이 있는지 찾아봐야겠습니다.

pcmoore 에 2019년 02월 05일

Ubuntu 16.04(Xenial)를 사용할 수 있는 것 같습니다. 시도해 보겠습니다.

pcmoore 에 2019년 02월 05일

Commit 06f63ba691cb9df119c6759e8f0a150a2a9cbe69는 Ubuntu 16.04까지 올라갑니다. 이 스위치를 강제 실행하고 싶기 때문에 PR이 아닌 마스터 브랜치에서 이 작업을 수행하고 있습니다. 빌드가 중단되면 수정하겠습니다.

https://travis-ci.org/seccomp/libseccomp/builds/489230929

pcmoore 에 2019년 02월 05일

👍1

그 빌드는 테스트 문제를 해결한 것 같았지만, clang은 오류 처리 코드 경로에서 메모리 누수를 발견했습니다. 잠시 후에 수정하겠습니다.

pcmoore 에 2019년 02월 05일

엄청난! 도움을 주셔서 감사합니다, @pcmoore

drakenclimber 에 2019년 02월 05일

좋아, 커밋 f8854f990004e71ccb9955c33d88d82cdb97ea42를 사용하면 깨끗한 건물 마스터 브랜치가 있어야 합니다. 지금 메인 빌드를 기다리는 내 개인 지점에서 잘 작동했습니다.

pcmoore 에 2019년 02월 05일

@drakenclimber 위의 문제 로그에서 이에 대한 패치가 준비된 것을 보았지만 아직 PR을 볼 수 없습니다. 여전히 패치와 관련된 몇 가지 문제를 추적하고 있습니까 아니면 PR을 위한 준비가 되어 있습니까?

pcmoore 에 2019년 02월 18일

이것은 커밋 4a35b6ea6f7c836734536420c50a2745a9e24c69로 해결되어야 하며 지금 종료해야 합니다. 누군가 이 문제를 발견하면 이 문제를 다시 열거나 새 문제를 만드십시오.

pcmoore 에 2019년 02월 18일

이 페이지가 도움이 되었나요?

0 / 5 - 0 등급

Libseccomp: 버그: seccomp_arch_add()는 엔디안 불일치 시 -EEXISTS를 반환합니다.

모든 18 댓글

46은 지적한 대로 ERROR 를 반환합니다. 그리고 #47은 FAILURE 반환합니다(이는 내가 원래 검색한 것입니다.)

관련 문제

46은 지적한 대로 `ERROR` 를 반환합니다. 그리고 #47은 `FAILURE` 반환합니다(이는 내가 원래 검색한 것입니다.)