[논문 리뷰] A Systematic Impact Study for Fuzzer-Found Compiler Bugs

Michaël Marcozzi, Qiyi Tang외 2명|arXiv (Cornell University)|2019. 02. 25.

Software Testing and Debugging Techniques참고 문헌 38인용 수 7

한 줄 요약

이 논문은 Clang/LLVM에서 컴파iler 패ッチ 퍼포머에 의해 발견되거나 사용자 보고된 컴파일러 버그의 실제 영향을 체계적이고 경험적으로 평가하는 연구를 제시한다. 309개의 Debian 패키지와 1,000만 줄이 넘는 C/C++ 코드를 분석하여, 퍼포머에 의해 발견된 오류 중 약 46%가 생성된 바이너리에 영향을 미치는 것으로 밝혀졌지만, 테스트 셋 실패 사례는 단 두 건 뿐이었으며, 대부분의 변경 사항은 드문 트리거링 조건과 보수적인 컴파일러 최적화로 인해 의미 있는 영향을 거의 또는 전혀 미치지 못했다.

ABSTRACT

Despite much recent interest in compiler randomized testing (fuzzing), the practical impact of fuzzer-found compiler bugs on real-world applications has barely been assessed. We present the first quantitative and qualitative study of the tangible impact of miscompilation bugs in a mature compiler. We follow a rigorous methodology where the bug impact over the compiled application is evaluated based on (1) whether the bug appears to trigger during compilation; (2) the extent to which generated assembly code changes syntactically due to triggering of the bug; and (3) how much such changes do cause regression test suite failures and could be used to manually trigger divergences during execution. The study is conducted with respect to the compilation of more than 10 million lines of C/C++ code from 309 Debian packages, using 12% of the historical and now fixed miscompilation bugs found by four state-of-the-art fuzzers in the Clang/LLVM compiler, as well as 18 bugs found by human users compiling real code or by formal verification. The results show that almost half of the fuzzer-found bugs propagate to the generated binaries for some packages, but rarely affect their syntax and cause two failures in total when running their test suites. User-reported and formal verification bugs do not exhibit a higher impact, with less frequently triggered bugs and one test failure. Our manual analysis of a selection of bugs, either fuzzer-found or not, suggests that none can easily trigger a runtime divergence on the packages considered in the analysis, and that in general they affect only corner cases.

연구 동기 및 목표

• Clang/LLVM와 같은 성숙한 컴파일러에서 퍼포머에 의해 발견된 오류의 실제 영향을 정량적이고 정성적으로 평가하는 것.
• 실제 응용 프로그램에서 퍼포머에 의해 발견된 버그와 사용자 보고 또는 형식적 검증된 버그의 영향을 비교하는 것.
• 버그로 인해 발생하는 생성된 어셈블리 코드의 구문적 변경이 실제 실행 차이 또는 실질적 소프트웨어 패키지의 테스트 실패를 유도하는지 평가하는 것.
• 버그로 인한 바이너리 차이의 빈도와 의미적 중요성이 실제 소프트웨어 생산 환경에서의 실질적 위험과 관련이 있는지 평가하는 것.
• 실제 코드베이스에 미치는 영향과 관련하여 버그 심각도가 실제 영향과 관련이 있는지 평가함으로써 컴파일러 개발 우선순위를 안내하는 것.

제안 방법

• 최신 컴파일러 퍼포머(예: Csmith, Yarpgen)에서 발견한 역사적 고쳐진 오류 중 12%를 선별하고, 사용자 보고 및 형식적 검증에서 유래한 18개의 비퍼포머 기반 오류를 포함한다.
• Clang/LLVM 컴파일러를 사용하여 309개의 Debian 패키지에서 1,000만 줄이 넘는 C/C++ 코드를 버그 최적화 기능을 켜거나 끈 상태에서 컴파일한다.
• 세 가지 기준을 통해 영향을 측정한다: (1) 컴iles 중에 버그가 트리거되었는지 여부, (2) 어셈블리 코드 변경의 구문적 범위, (3) 변경 사항이 테스트 셋 실패 또는 런타임 다름을 유도했는지 여부.
• 특정 런타임 조건에서 실행 다름이 발생할 수 있는지 평가하기 위해 선택된 어셈블리 코드 변경 사항에 대한 수동 분석을 수행한다.
• 보수적인 추론을 사용하여 영향을 추정하며, 프로그램 의미를 변경하는 경우에만 의미 있는 영향으로 간주하고, 성능 또는 보안과 같은 비기능적 영향은 제외한다.
• 수정 패치를 평가하여 잠재적으로 해로운 최적화를 비활성화했는지 이해하고, 이로부터 관측된 바이너리 차이가 유의미하게 유해한지 또는 무해한지 추론한다.

실험 결과

연구 질문

• RQ1 Clang/LLVM에서 퍼포머에 의해 발견된 오류가 실제 C/C++ 응용 프로그램 컴파일에 얼마나 영향을 미치는가?
• RQ2 버그의 영향이 바이너리 수정 및 테스트 셋 실패 측면에서 사용자 보고 또는 형식적 검증된 버그와 비교해 볼 때 어떻게 다른가?
• RQ3 오류로 인한 생성된 어셈블리 코드의 구문적 변경 사항은 의미적으로 중요한가, 아니면 일반적으로 프로그램 동작에 영향을 주지 않는가?
• RQ4 어떤 런타임 조건이 존재할 경우, 이러한 바이너리 차이가 실제 응용 프로그램에서 실행 다름을 유도하는가?
• RQ5 수정 패치의 특성(예: 최적화 비활성화)은 원래 버그가 초래하는 실제 위험과 어떻게 관련이 있는가?

주요 결과

• 퍼포머에 의해 발견된 오류 중 약 46% (역사적 수정 버그의 12%)가 적어도 한 개 이상의 Debian 패키지에서 생성된 바이너리에 구문적 변경을 일으켰다.
• 모든 영향을 받은 패키지에서 컴파일 시 버그가 포함된 컴파일러를 사용했을 때 테스트 셋 실패 사례가 단 두 건 뿐이었으며, 이는 광범위한 바이너리 수정에도 불구하고 실질적 영향이 낮음을 시사한다.
• 수동 분석 결과, 대부분의 오류로 인한 어셈블리 코드의 구문적 변경 사항은 의미적 영향을 주지 않았으며, 일반적으로 보수적인 컴파일러 최적화나 드문 런타임 조건으로 인해 발생했다.
• EMI Bug #30935는 잘못된 나눗셈 연산 이동을 포함했으며, 수정 패치는 비상수 나눗셈자에 대한 이동을 비활성화하여 위험을 감소시켰지만, 트리거링 빈도가 낮아 버그의 영향은 여전히 낮았다.
• 사용자 보고 및 형식적 검증된 버그는 트리거 빈도가 낮았고, 테스트 실패 사례도 한 건 뿐이었으며, 이는 퍼포머에 의해 발견된 버그보다 실제 영향이 높지 않음을 시사한다.
• 바이너리의 구문적 변경이 있음에도 불구하고 대부분의 버그는 실행 다름을 유도하지 않았다. 이는 변경 사항이 의미적으로 무해하거나 매우 특정한 런타임 조건이 충족되어야만 나타나기 때문이었다.