GPU 프로그램의 숨은 메모리 버그 추적

초록

본 논문은 입력에 따라 발생하는 CUDA 프로그램의 경계 초과(OOB) 버그와 단일 할당 내부에서 발생하는 intra‑allocation OOB를 정적 분석으로 탐지하는 SCuBA 도구를 제안한다. SCuBA는 CPU와 GPU 코드 간 변수 관계를 SAT 제약식으로 모델링해 모든 입력에 대해 OOB 가능성을 검증하고, 기존 런타임 기반 도구가 놓치는 45개의 버그를 놓치지 않는다.

상세 분석

SCuBA는 GPU 프로그램의 메모리 안전성을 정적 분석으로 확보한다는 점에서 기존 연구와 근본적으로 차별화된다. 기존의 런타임 기반 도구들은 메모리 할당과 접근을 실행 시점에 추적하고, 실제 OOB가 발생해야만 경고를 출력한다. 따라서 입력에 따라 OOB가 나타나는 경우, 테스트 입력이 “우연히” 해당 경로를 실행하지 않으면 버그를 놓치게 된다. 논문은 이러한 현상을 “input‑dependent OOB”라 명명하고, 실제 오픈소스 CUDA 프로젝트와 라이브러리에서 수십 건의 사례를 발견한다. 특히, host 코드에서 사용자 입력에 기반해 할당 크기를 결정하고, kernel에서는 threadIdx·blockIdx 등을 이용해 오프셋을 계산하는 전형적인 패턴에서 변수 간 의미적 관계가 깨지는 경우가 버그의 원인임을 강조한다.

핵심 아이디어는 “semantic relation”이다. 할당 크기를 결정하는 변수(예: problem size, matrix dimension)와 그 할당을 접근하는 오프셋을 계산하는 변수(예: threadIdx·gridDim)의 관계를 정량화한다. 관계가 존재하면 오프셋이 할당 범위를 초과할 가능성이 없으며, 관계가 부재하거나 불명확하면 OOB 가능성을 가정한다. 이를 위해 SCuBA는 LLVM‑MLIR 기반의 중간 표현을 활용해 host와 kernel 양쪽의 변수 흐름을 추적하고, 각 변수 간 연산 관계를 수식화한다. 이후 Google OR‑Tools의 SAT Solver에 제약식으로 입력해 “offset ≤ size‑1”이 모든 가능한 입력에 대해 만족되는지 검증한다. 만족하지 않으면 OOB가 존재할 수 있다고 판단한다.

또 다른 중요한 기여는 “intra‑allocation OOB” 탐지이다. CUDA의 동적 shared memory에서는 하나의 버퍼를 여러 논리적 데이터 구조로 나누어 사용한다. 기존 도구들은 버퍼 전체의 경계만 검사하므로, 서로 다른 논리 구조 간 경계 초과를 감지하지 못한다. SCuBA는 포인터 연산과 구조체 레이아웃을 IR 수준에서 분석해 논리적 파티션 경계를 식별하고, 각 파티션에 대한 오프셋 제약을 별도로 생성한다. 이렇게 하면 동일 버퍼 내에서도 잘못된 파티션을 참조하는 경우를 정확히 포착한다.

성능 측면에서 SCuBA는 정적 분석 단계에서만 비용이 발생한다. 실제 실행 시 오버헤드가 전혀 없으며, SAT Solver 호출 횟수는 프로그램 규모에 비례해 제한적이다. 논문에서는 20개의 실험 워크로드(총 45개 OOB)에서 NVIDIA Compute Sanitizer가 놓친 모든 버그를 잡아냈으며, false positive는 전혀 보고되지 않았다. 이는 정적 분석이 런타임 검증보다 높은 정확도와 완전성을 제공할 수 있음을 실증한다.

한계점으로는 복잡한 포인터 연산이나 비정형 메모리 접근(예: 함수 포인터를 통한 동적 주소 계산)에서 관계 추출이 어려울 수 있다. 또한, SAT Solver의 해답이 “unsat”일 경우에도 실제 실행 환경에서 특수한 하드웨어 동작이나 비동기 이벤트가 OOB를 일으킬 가능성을 완전히 배제하지는 못한다. 그럼에도 불구하고, SCuBA는 현재 GPU 메모리 안전 분야에서 가장 포괄적인 정적 검증 프레임워크로 평가된다.