Challenges and Design Considerations for Finding CUDA Bugs Through GPU-Native Fuzzing

이 논문은 CPU-GPU 이종 시스템의 메모리 안전성 문제를 해결하기 위해, 기존 CPU 기반 테스트의 한계를 극복하고 실제 GPU 아키텍처의 특성을 정확히 반영하는 'GPU 네이티브 퍼징' 파이프라인의 설계 고려사항과 핵심 과제를 제시합니다.

핵심

🏗️ 1. 상황: "완벽한 주방과 낡은 조리대"

과거에는 컴퓨터가 CPU(중앙 처리 장치) 하나만 가지고 모든 일을 했습니다. CPU 는 수십 년 동안 보안과 안전 장치를 철저히 다져서 '안전한 주방'처럼 변했습니다.

하지만 요즘은 AI 나 과학 시뮬레이션 같은 무거운 일을 처리하기 위해 GPU(그래픽 처리 장치) 라는 '특수 조리대'를 함께 쓰게 되었습니다. 문제는 이 **GPU 쪽은 아직 안전 장치가 거의 없는 '낡은 조리대'**라는 점입니다.

• 현재 상황: CPU 는 방범 시스템이 완벽하지만, GPU 는 문이 잠겨 있지 않아 도둑 (해커) 이 들어오기 쉽습니다.
• 위험성: 이 낡은 조리대에서 일하는 요리사 (AI 모델 등) 가 실수하면, 중요한 데이터가 유출되거나 음식 (데이터) 이 망가질 수 있습니다.

🚫 2. 기존 방법의 문제점: "번역기의 함정"

지금까지 연구자들은 GPU 의 버그 (결함) 를 찾기 위해 CPU 에서 GPU 프로그램을 돌려보며 테스트하는 방법을 썼습니다.

• 비유: "중국 요리 (GPU 프로그램) 의 맛을 보려면, 일단 한국식 재료로 바꿔서 한국 요리사 (CPU) 가 만들어보게 한 뒤, 그 맛을 보고 '아, 중국 요리도 이럴 거야'라고 추측하는 것"과 같습니다.
• 문제점: 중국 요리와 한국 요리는 재료와 조리법이 완전히 다릅니다. 번역 과정에서 중요한 맛 (버그) 이 사라지거나, 원래 없던 이상한 맛이 날 수 있습니다. 즉, 현실과 다른 테스트를 하는 것이죠.

🔍 3. 연구팀의 제안: "현장 (GPU) 에서 직접 검사하기"

이 논문은 **"GPU 가 실제로 일하는 현장 (GPU 하드웨어) 에서 직접 버그를 찾아야 한다"**고 주장합니다. 이를 위해 'GPU 네이티브 퍼징 (GPU-Native Fuzzing)'이라는 새로운 검사 시스템을 만들려고 합니다.

🔧 4가지 주요 난관과 해결책

이 시스템을 만들 때 겪는 4 가지 어려움과 해결책을 비유로 설명하면 다음과 같습니다.

① 안전장치가 없다 (Sanitization)

• 문제: CPU 에는 "너무 많은 재료를 넣으면 터진다"라고 경고해주는 안전장치가 있지만, GPU 에는 없습니다.
• 해결: GPU 내부에 직접 감시 카메라 (인스트루멘테이션) 를 설치해서, 메모리를 건드릴 때마다 "여기 위험하다!"라고 바로 경고하고 멈추게 합니다.

② 입력값을 어떻게 변형할지 모른다 (Mutation)

• 문제: 버그를 찾으려면 무작위 입력값을 넣어야 하는데, GPU 는 매우 특수한 규칙을 따릅니다. 아무거나 넣으면 바로 거절당합니다.
• 해결: GPU 의 특성을 잘 아는 전문가처럼, 숫자나 배열의 '비밀 코드'를 살짝 바꿔주며 (타입 인식 변형) "이런 경우엔 어떻게 반응할까?"를 테스트합니다.

③ 어디까지 테스트했는지 모른다 (Coverage Tracking)

• 문제: "우리가 이 프로그램을 얼마나 꼼꼼히 다 봤는지"를 알 수 없습니다.
• 해결: GPU 가 실행하는 모든 길 (코드 경로) 에 센서를 달아, "여기까지 갔다!"라고 기록합니다. 아직 안 간 길로 더 많이 가도록 유도합니다.

④ 테스트 환경을 세우는 게 너무 어렵다 (Fuzzing Harness)

• 문제: GPU 프로그램을 테스트하려면 복잡한 준비 과정 (메모리 할당, 초기화 등) 이 필요합니다. 이걸 매번 다 하면 시간이 너무 걸립니다.
• 해결: 준비 과정은 한 번만 하고, 실제 테스트 (요리) 부분만 반복해서 돌리는 '효율적인 루프'를 만듭니다.

📊 5. 실험 결과: "아직 갈 길이 멀다"

연구팀은 NVIDIA 의 유명한 라이브러리 (cuBLAS) 를 이 방법으로 테스트해 봤습니다.

• 결과: 기존에 제공된 테스트 데이터로는 GPU 코드의 약 26% 만 실행되었습니다.
• 의미: 나머지 **74% 는 아직 아무도 가보지 않은 '어둠 속'**입니다. 이 어둠 속에 숨겨진 치명적인 버그들이 있을 수 있다는 뜻입니다.

💡 6. 결론: "윤리적 책임"

이 논문의 핵심 메시지는 단순한 기술적 문제를 넘어 윤리적입니다.

"우리가 가장 첨단 AI 와 과학 기술을 GPU 위에서 돌리고 있는데, 그 기반이 너무 불안정하다면 어떡합니까? 현장에서 직접, 정확하게 안전을 검증하는 것은 기술자의 윤리적 책임입니다."

요약하자면, 이 논문은 **"번역기를 믿지 말고, 직접 현장 (GPU) 에 가서 안전장치를 설치하고, 꼼꼼히 테스트하자"**고 제안하는 연구입니다.

기술 요약

1. 문제 정의 (Problem)

• 이종 시스템의 보안 격차: 현대 컴퓨팅은 CPU 중심의 동질적 시스템에서 CPU 와 GPU 가 긴밀하게 통합된 이종 (Heterogeneous) 시스템으로 전환되고 있습니다. 그러나 CPU 소프트웨어 스택은 수십 년간의 메모리 안전성 강화 (정적/동적 분석, 메모리 안전 언어 등) 를 거친 반면, GPU 소프트웨어 스택은 상대적으로 미성숙하여 보안 취약점이 많습니다.
• 악용 가능한 버그의 증가: 머신러닝 워크로드의 인기와 함께 NVIDIA 와 AMD GPU 에서 발견되는 악용 가능한 취약점 (CVE) 의 수가 급격히 증가하고 있습니다. 이러한 메모리 안전성 버그는 ROP(Return-Oriented Programming) 공격, 데이터 유출, 무음 데이터 손상 (Silent Data Corruption) 등을 초래할 수 있습니다.
• 기존 완화 방법의 한계: 현재 존재하는 대부분의 보안 완화 및 테스트 방법은 GPU 프로그램을 CPU 로 변환 (Translation) 하여 테스트하는 방식을 사용합니다. 그러나 CPU 와 GPU 간의 복잡한 아키텍처 차이로 인해 프로그램의 동작이 정확히 반영되지 않아 (Unfaithful translation), 중요한 버그를 놓치거나 (False Negative) 잘못된 경보를 발생시키는 (False Positive) 문제가 있습니다.
• GPU 네이티브 퍼징의 부재: CPU 에서는 널리 사용되는 퍼징 (Fuzzing) 기법을 GPU 에 적용하는 데는 다음과 같은 핵심적인 기술적 장벽이 존재합니다.
  1. Sanitization 부재: GPU 에 적용 가능한 주소 정리 (Address Sanitization) 도구가 부족합니다.
  2. 입력 변형 (Mutation) 부재: 병렬 CUDA 커널의 메모리 안전성 버그를 유발할 수 있는 아키텍처 특화 변형 연산자가 없습니다.
  3. 커버리지 추적 부재: GPU 코드 실행 중 커버리지를 추적하는 것이 어렵습니다.
  4. 퍼징 하네스 (Harness) 부재: GPU 프로그램은 특정 컨텍스트 초기화, JIT 컴파일, CPU-GPU 협업 실행이 필요하여 기존 CPU 퍼징 하네스를 적용하기 어렵습니다.

2. 방법론 (Methodology)

저자들은 CPU 변환 방식이 아닌, GPU 네이티브 (GPU-Native) 퍼징 파이프라인을 제안합니다. 이 방식은 테스트 로직을 GPU 하드웨어 자체로 이동시켜 프로그램 동작의 정확성 (Faithfulness) 을 보장합니다.

• 동적 바이너리 인스트루멘테이션 (Dynamic Binary Instrumentation, DBI) 활용:

  • NVIDIA 의 오픈소스 DBI 도구인 NVBit를 사용하여 GPU 커널 실행 시 메모리 접근 및 제어 흐름을 실시간으로 계측합니다.
  • 커스텀 하드웨어 변경 없이 상용 (Commodity) NVIDIA GPU 에서 작동하도록 설계되었습니다.

• 주요 구성 요소:

  1. GPU 네이티브 주소 정리 (Address Sanitization):
     • GPU 글로벌, 로컬, 공유 메모리 및 포인터에 대한 메타데이터를 유지하며 메모리 접근 시 버그 (버퍼 오버플로우, Use-after-free 등) 를 탐지합니다.
     • GPU 의 병렬성을 활용하여 오버헤드를 줄이고 성능을 향상시킵니다.
  2. 커버리지 추적 (Coverage Tracking):
     • NVBit 를 통해 GPU 제어 흐름 지시어 (Control Flow Instructions) 를 계측하여 실행 횟수를 카운트합니다.
     • 이를 퍼징 피드백으로 활용하여 새로운 코드 경로를 탐색하는 입력을 생성합니다.
  3. 컨텍스트 민감형 퍼징 (Context-Sensitive Fuzzing):
     • 폐쇄형 (Closed-source) NVIDIA 라이브러리는 저수준 커널이 고수준 커널을 통해만 호출되는 경우가 많습니다. 이를 해결하기 위해 라이브러리 예제 코드를 초기화 (Initialization), 계산 (Computation), 종료 (Termination) 단계로 분할합니다.
     • 초기화와 종료 단계는 한 번 수행하고, 계산 단계만 반복 실행하여 퍼징 오버헤드를 줄입니다.
  4. 타입 인식 변형 (Type-Aware Mutations):
     • 단순 바이트 단위 변형이 아닌, 커널의 인자 타입에 맞춘 변형 전략을 적용합니다.
     • 정수: 0, 최대/최소 값, 오버플로우 값 변형.
     • 부동소수점: 부호, 가수, 지수 비트를 조작하는 전략 적용.
     • 배열: 값 변형 (크기, 차원 변경) 및 포인터 변형 (전역/로컬/공유 메모리 영역 변경) 을 수행하여 경계 조건 버그를 유발합니다.

3. 주요 기여 (Key Contributions)

• 윤리적 책임 강조: 이종 시스템의 설계자가 GPU 프로그램을 GPU 에서 직접 검증해야 할 윤리적 책임을 강조하며, 변환 기반 테스트의 위험성을 지적했습니다.
• GPU 네이티브 퍼징 파이프라인 제안: NVBit 를 기반으로 한 최초의 종합적인 GPU 네이티브 정제 및 퍼징 아키텍처를 설계했습니다. 이는 폐쇄형 라이브러리와 상용 하드웨어에서도 작동합니다.
• 새로운 변형 전략 개발: CPU 퍼징과 구별되는 GPU 특화 타입 인식 변형 (Type-Aware Mutations) 과 컨텍스트 민감형 실행 분할 기법을 제시하여 퍼징 효율성을 극대화했습니다.
• 실제 데이터 기반 분석: cuBLAS 라이브러리 샘플을 대상으로 한 실험을 통해 기존 테스트 방법의 커버리지 한계를 입증했습니다.

4. 실험 결과 (Results)

• 실험 환경: Ubuntu 22.04, AMD EPYC CPU, NVIDIA A100 GPU, CUDA 13.1 환경에서 수행되었습니다.
• 커버리지 분석: NVIDIA 의 폐쇄형 라이브러리인 cuBLAS의 11 개 샘플을 분석한 결과, 기존 라이브러리 예제 입력만으로는 평균 **25.98%**의 기본 블록 (Basic Block) 커버리지만 달성했습니다.
  • 가장 높은 커버리지를 보인 asum 은 64.29% 였으나, 가장 낮은 rotm 은 9.09% 에 불과했습니다.
• 시사점: 이 결과는 기존 테스트 입력으로는 GPU 프로그램의 복잡한 상태 공간을 충분히 탐색하지 못하고 있음을 보여주며, 제안된 GPU 네이티브 퍼징 파이프라인이 이러한 격차를 해소할 필요성을 입증했습니다.

5. 의의 및 결론 (Significance)

• 보안 패러다임의 전환: CPU 중심의 보안 접근법을 탈피하여, GPU 의 고유한 아키텍처 특성을 반영한 네이티브 보안 검증 체계를 정립했습니다.
• 신뢰성 있는 AI 및 과학 컴퓨팅: 머신러닝 및 고성능 과학 시뮬레이션의 핵심 인프라인 GPU 의 메모리 안전성을 보장함으로써, 데이터 유출 및 시스템 오작동 위험을 줄이는 데 기여합니다.
• 실용성: 커스텀 하드웨어 없이 상용 GPU 에서 작동 가능하므로, 실제 산업 환경에 즉시 적용 가능한 솔루션을 제시합니다.

요약하자면, 이 논문은 이종 시스템의 보안 격차를 해소하기 위해 GPU 네이티브 환경에서의 정밀한 퍼징이 필수적임을 주장하고, 이를 실현하기 위한 구체적인 기술적 설계 (NVBit 기반 인스트루멘테이션, 컨텍스트 분할, 타입 인식 변형) 와 초기 검증 결과를 제시한 연구입니다.