noriwiki - 사용자 기여 [ko]

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가지 요소들은 서로 중복되는 면이 없지 않는가 하는 생각이 들었다.

Principles and Methodologies for Serial Performance Optimization

2026-03-19T02:22:23Z

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를 제안한다. 기존에는 성능 최적화가 경험과 직관에 의존했으나, 본 논문은 이를 구조화된...

파일:USENIX OSDI 2025 Sujin, Park Table 1.png

2026-03-18T12:03:04Z

Ahn9807:

Table 1: Summary of the eight methodologies, detailing their underlying principles, visual representations, necessary conditions, and strategic applications.

Fast Pointer Nullification for Use-After-Free Prevention

2026-03-18T08:03:10Z

Ahn9807:

[[분류:NDSS]]

{{Paper|title=Fast Pointer Nullification for Use-After-Free Prevention|author=Yubo Du University of Pittsburgh yubo.du@pitt.edu Youtao Zhang University of Pittsburgh youtao@pitt.edu Jun Yang University of Pittsburgh juy9@pitt.edu|conference=NDSS 2026|year=2026}}

== 개요 ==
[[Pointer nullification]]기법은 [[Use-after-free]]버그를 효과적으로 막을 수 있지만, 기존의 PN (Pointer nullification)기법들은 메타데이터 Lookup에 많은 시간이 사용되기 때문에 효율적으로 사용하기는 어려웠다.

이 논문은 '''Fast Pointer Nullification (FPN)'''이라는 기법을 제안하여, 최적화된 PN을 통해 UAF 탐지 및 방지의 성능을 향상시키는 것을 목표로 한다.

기존 PN의 핵심 병목이었던 metadata lookup을 단순화하고, 공간적 지역성을 활용한 새로운 저장 구조를 통해 성능과 메모리 오버헤드를 동시에 줄인다.

== Motivation & Importance ==
UAF 버그는 dangling pointer가 해제된 메모리를 참조하면서 발생하는 취약점으로, arbitrary code execution 등 심각한 보안 문제로 이어질 수 있다.

이를 방지하기 위한 다양한 기법이 존재하지만, 성능(Performance), 메모리 사용량(Memory consumption), 보안(Security), 호환성(Compatibility) 측면에서 trade-off가 존재한다.

그중 Pointer Nullification (PN)기법은 이러한 trade-off를 비교적 균형 있게 만족하는 방식으로 평가된다.

== Background ==
[[파일:NDSS 2026 FPN Figure 2.png|섬네일|오른쪽]]
Pointer Nullification은 다음과 같은 방식으로 동작한다:

# heap object가 생성될 때 metadata를 생성한다.
# pointer가 특정 object를 가리킬 때, 해당 pointer의 저장 위치를 metadata에 기록한다.
# object가 free될 때, 해당 object를 가리키는 모든 pointer를 찾아 null로 설정한다.

즉, dangling pointer가 생성되는 것을 사전에 제거하여 UAF를 방지하는 방식이다.

하지만 PN 기법에는 다음과 같은 문제가 존재한다:

* pointer → object 관계를 추적하기 위한 metadata lookup 비용이 매우 큼
* CAMP 기준으로 약 62.5%의 성능 오버헤드가 lookup에서 발생
* metadata를 tree/hash 구조로 저장 → cache locality가 매우 나쁨

또한 pointer 저장 위치들은 실제로는 공간적으로 밀집되어 있는 경우가 많음에도 불구하고, 이를 활용하지 못하는 비효율이 존재한다.

== Main Idea ==
이 논문은 Fast Pointer Nullification이라는 기법을 도입하였다.

FPN은 두 가지 핵심 최적화 디자인을 포함한다:

* Constant-time and lightweight metadata address computation: pointer가 속한 metadata 위치를 bit-shift 연산으로 계산하여 O(1) 접근
* Spatial locality 활용: individual pointer storage location 대신 <math>2^M</math> byte-aligned memory block 단위로 관리

즉,
* 기존 PN: pointer 단위 tracking
* FPN: block 단위 tracking

을 통해 metadata lookup과 registration 비용을 동시에 줄인다.

== Challenge ==
* PN 방식은 pointer가 어떤 연결관계를 맺는지를 기억해야 한다. 이 metadata lookup 비용이 매우 크다.
** DangNULL: Red-black tree 사용 → O(log n)
** CAMP: 최적화했지만 여전히 높은 비용
** 전체 성능 오버헤드 중 약 62.50%가 lookup에서 발생
* metadata가 spatial locality를 전혀 반영하지 못한다.
** hash / tree 기반 구조 → 메모리 상에 무작위 배치
** pointer 저장 위치는 실제로 인접한 경우가 많음에도 불구하고 이를 활용하지 못함
** cache miss 증가 및 성능 저하 발생

== Design ==
[[파일:NDSS 2026 FPN Figure 4.png|프레임|가운데]]

FPN은 기존 PN의 동작 구조를 유지하면서 내부 메커니즘을 최적화한다.

여기서 Buffer는 Allocation된 Heap메모리를, Pointer는 그 Buffer를 가르키는 포인터를 의미한다. 예를 들어서 Pointer A = Buffer; 이 있을때, Pointer B = A;면 Pointer A와 Pointer B는 동시에 같은 Buffer B를 가르키고, 과연 어떻게 이러한 종속관계를 빠르게 추적할 수 있는 자료구조를 만들 수 있을지가 이 논문의 핵심이다.

=== Region-based Metadata ===
메모리를 2^N byte 단위 region으로 분할하고 pointer가 속한 region을 다음과 같이 계산한다:

region_id = ptr >> N

각 region은 다음 정보를 포함한다:
* buffer list: 이 리전에 포함된 버퍼들의 리스트를 가지고 있다. 이 리스트는 Buffer info로 관리되며 각 Buffer info는 할당된 메모리들의 Start address와 End address가 있다.
* block list: 이 리전을 가르키는 포인터들이 어떤 Block에 속하는 지에 대한 리스트를 가지고 있다.

이를 통해 metadata lookup을 constant-time으로 수행할 수 있다.

=== Block-based Pointer Registration ===
기존 PN는 pointer 저장 위치를 개별적으로 기록하지만 FPN과 같은 경우는 pointer가 속한 block 단위로 등록한다.

block_addr = store_loc & ~(2^M - 1)

동작:
# pointer → region 계산
# region의 block list 접근
# 최근 block들과 비교하여 중복 제거
# 새로운 block만 등록 (이 Region에는 Block 1과 Block 2에 해당하는 포인터들이 있다. 즉 Possible한 Pointer의 Range를 가지고 있는 것)

효과:
# registration 횟수 감소
# metadata 크기 감소
# cache locality 향상

=== Nullification 과정 ===
object free 시:
# 해당 object가 속한 region 확인
# region의 block list 순회
# 각 block 내 pointer 후보 탐색
# 해당 object를 가리키는 pointer를 null로 설정
# Region에서 Buffer info제거

특징:
* pointer를 정확히 저장하지 않고 block 단위로 탐색
* '''deallocation frequency가 낮기 때문에 overhead는 제한적'''

=== Status Bit (False Positive 방지) ===
문제: block 단위 탐색 시 pointer가 아닌 값까지 nullify될 위험 존재한다.

해결: shadow memory 기반 status bit 사용

status_table[address >> 3]
* pointer 저장 시 bit 설정
* free 시 bit 제거

효과:
* false positive 제거
* 안전한 nullification

== Evaluation ==
=== 성능 및 메모리 오버헤드 ===
: SPEC CPU 2017 기준으로 분석하였을 경우
* 성능 오버헤드: 약 17.78%
* 메모리 오버헤드: 약 8.34%

; 기존 PN 대비 크게 개선된 사항
* CAMP: ~56% performance / ~173% memory
* FreeSentry: 높은 메모리 오버헤드

== [[Conclusion]] ==
FPN은 기존 Pointer Nullification의 핵심 병목이었던 metadata lookup 비용과 pointer registration를 Corased-grained block-based region search로 변경하여 문제를 해결하였다. 그결과, 낮은 성능 및 메모리 오버헤드를 가져올 수 있었다. 논문의 몇몇 가정은 동의하기 힘든 부분도 있었지만, "E.g., Page 5, "ALthough scanning entire blocks during nullification may introduce additional performance overhead, deallocations occur infrequently in most applications", [[BUDAlloc: Defeating Use-After-Free Bugs by Decoupling Virtual Address Management from Kernel|BUDAlloc]]과 [[SwiftSweeper]]를 평가에 반영하였기 때문에 매우 높은 점수를 주고 싶다.

Minor comments:

# Buffer information이 설명없이 그림에만 나와서, 알고리즘을 이해하는데 조금 어려웠다.

Major comments:

# Deallocation frequency가 낮기 때문에 Free성능이 병목이 되지 않는 다고 주장하고 있지만, 이 부분에 대한 명시적인 증거가 필요해 보인다. 추측해 보건데, Deallocation frequency가 낮은 것이 아니라, 단순히 Pointer tracking이 Deallocation시의 Overhead를 감수할만큼 더 많이 Overhead를 줄인 것으로 추측된다.
# Performance overhead관점에서 보았을 경우, FPN은 Pointer nullification의 단점인 Overhead를 확실히 많이 끌어 올린 것은 맞지만, 기존의 FFmalloc과 같은 논문과 비교하여 아직 부족한 부분이 있다. Pointer nullification을 좀더 빠르게 만들 수 있는 방법으로, Block tracking 내부적으로 Hash를 이용하는 방법이나, 아니면 LLVM컴파일러의 도움을 받는 부분도 탐색하면 좋을 것 같다는 생각이 든다.

Fast Pointer Nullification for Use-After-Free Prevention

2026-03-18T08:02:53Z

Ahn9807: 새 문서: index.php?title=분류:NDSS {{Paper|title=Fast Pointer Nullification for Use-After-Free Prevention|author=Yubo Du University of Pittsburgh yubo.du@pitt.edu Youtao Zhang University of Pittsburgh youtao@pitt.edu Jun Yang University of Pittsburgh juy9@pitt.edu|conference=NDSS 2026|year=2026}} == 개요 == Pointer nullification기법은 Use-after-free버그를 효과적으로 막을 수 있지만, 기존의 PN (Pointer nullification)기법들은 메타데이터 Looku...

[[index.php?title=분류:NDSS]]

{{Paper|title=Fast Pointer Nullification for Use-After-Free Prevention|author=Yubo Du University of Pittsburgh yubo.du@pitt.edu Youtao Zhang University of Pittsburgh youtao@pitt.edu Jun Yang University of Pittsburgh juy9@pitt.edu|conference=NDSS 2026|year=2026}}

== 개요 ==
[[Pointer nullification]]기법은 [[Use-after-free]]버그를 효과적으로 막을 수 있지만, 기존의 PN (Pointer nullification)기법들은 메타데이터 Lookup에 많은 시간이 사용되기 때문에 효율적으로 사용하기는 어려웠다.

이 논문은 '''Fast Pointer Nullification (FPN)'''이라는 기법을 제안하여, 최적화된 PN을 통해 UAF 탐지 및 방지의 성능을 향상시키는 것을 목표로 한다.

기존 PN의 핵심 병목이었던 metadata lookup을 단순화하고, 공간적 지역성을 활용한 새로운 저장 구조를 통해 성능과 메모리 오버헤드를 동시에 줄인다.

== Motivation & Importance ==
UAF 버그는 dangling pointer가 해제된 메모리를 참조하면서 발생하는 취약점으로, arbitrary code execution 등 심각한 보안 문제로 이어질 수 있다.

이를 방지하기 위한 다양한 기법이 존재하지만, 성능(Performance), 메모리 사용량(Memory consumption), 보안(Security), 호환성(Compatibility) 측면에서 trade-off가 존재한다.

그중 Pointer Nullification (PN)기법은 이러한 trade-off를 비교적 균형 있게 만족하는 방식으로 평가된다.

== Background ==
[[파일:NDSS 2026 FPN Figure 2.png|섬네일|오른쪽]]
Pointer Nullification은 다음과 같은 방식으로 동작한다:

# heap object가 생성될 때 metadata를 생성한다.
# pointer가 특정 object를 가리킬 때, 해당 pointer의 저장 위치를 metadata에 기록한다.
# object가 free될 때, 해당 object를 가리키는 모든 pointer를 찾아 null로 설정한다.

즉, dangling pointer가 생성되는 것을 사전에 제거하여 UAF를 방지하는 방식이다.

하지만 PN 기법에는 다음과 같은 문제가 존재한다:

* pointer → object 관계를 추적하기 위한 metadata lookup 비용이 매우 큼
* CAMP 기준으로 약 62.5%의 성능 오버헤드가 lookup에서 발생
* metadata를 tree/hash 구조로 저장 → cache locality가 매우 나쁨

또한 pointer 저장 위치들은 실제로는 공간적으로 밀집되어 있는 경우가 많음에도 불구하고, 이를 활용하지 못하는 비효율이 존재한다.

== Main Idea ==
이 논문은 Fast Pointer Nullification이라는 기법을 도입하였다.

FPN은 두 가지 핵심 최적화 디자인을 포함한다:

* Constant-time and lightweight metadata address computation: pointer가 속한 metadata 위치를 bit-shift 연산으로 계산하여 O(1) 접근
* Spatial locality 활용: individual pointer storage location 대신 <math>2^M</math> byte-aligned memory block 단위로 관리

즉,
* 기존 PN: pointer 단위 tracking
* FPN: block 단위 tracking

을 통해 metadata lookup과 registration 비용을 동시에 줄인다.

== Challenge ==
* PN 방식은 pointer가 어떤 연결관계를 맺는지를 기억해야 한다. 이 metadata lookup 비용이 매우 크다.
** DangNULL: Red-black tree 사용 → O(log n)
** CAMP: 최적화했지만 여전히 높은 비용
** 전체 성능 오버헤드 중 약 62.50%가 lookup에서 발생
* metadata가 spatial locality를 전혀 반영하지 못한다.
** hash / tree 기반 구조 → 메모리 상에 무작위 배치
** pointer 저장 위치는 실제로 인접한 경우가 많음에도 불구하고 이를 활용하지 못함
** cache miss 증가 및 성능 저하 발생

== Design ==
[[파일:NDSS 2026 FPN Figure 4.png|프레임|가운데]]

FPN은 기존 PN의 동작 구조를 유지하면서 내부 메커니즘을 최적화한다.

여기서 Buffer는 Allocation된 Heap메모리를, Pointer는 그 Buffer를 가르키는 포인터를 의미한다. 예를 들어서 Pointer A = Buffer; 이 있을때, Pointer B = A;면 Pointer A와 Pointer B는 동시에 같은 Buffer B를 가르키고, 과연 어떻게 이러한 종속관계를 빠르게 추적할 수 있는 자료구조를 만들 수 있을지가 이 논문의 핵심이다.

=== Region-based Metadata ===
메모리를 2^N byte 단위 region으로 분할하고 pointer가 속한 region을 다음과 같이 계산한다:

region_id = ptr >> N

각 region은 다음 정보를 포함한다:
* buffer list: 이 리전에 포함된 버퍼들의 리스트를 가지고 있다. 이 리스트는 Buffer info로 관리되며 각 Buffer info는 할당된 메모리들의 Start address와 End address가 있다.
* block list: 이 리전을 가르키는 포인터들이 어떤 Block에 속하는 지에 대한 리스트를 가지고 있다.

이를 통해 metadata lookup을 constant-time으로 수행할 수 있다.

=== Block-based Pointer Registration ===
기존 PN는 pointer 저장 위치를 개별적으로 기록하지만 FPN과 같은 경우는 pointer가 속한 block 단위로 등록한다.

block_addr = store_loc & ~(2^M - 1)

동작:
# pointer → region 계산
# region의 block list 접근
# 최근 block들과 비교하여 중복 제거
# 새로운 block만 등록 (이 Region에는 Block 1과 Block 2에 해당하는 포인터들이 있다. 즉 Possible한 Pointer의 Range를 가지고 있는 것)

효과:
# registration 횟수 감소
# metadata 크기 감소
# cache locality 향상

=== Nullification 과정 ===
object free 시:
# 해당 object가 속한 region 확인
# region의 block list 순회
# 각 block 내 pointer 후보 탐색
# 해당 object를 가리키는 pointer를 null로 설정
# Region에서 Buffer info제거

특징:
* pointer를 정확히 저장하지 않고 block 단위로 탐색
* '''deallocation frequency가 낮기 때문에 overhead는 제한적'''

=== Status Bit (False Positive 방지) ===
문제: block 단위 탐색 시 pointer가 아닌 값까지 nullify될 위험 존재한다.

해결: shadow memory 기반 status bit 사용

status_table[address >> 3]
* pointer 저장 시 bit 설정
* free 시 bit 제거

효과:
* false positive 제거
* 안전한 nullification

== Evaluation ==
=== 성능 및 메모리 오버헤드 ===
: SPEC CPU 2017 기준으로 분석하였을 경우
* 성능 오버헤드: 약 17.78%
* 메모리 오버헤드: 약 8.34%

; 기존 PN 대비 크게 개선된 사항
* CAMP: ~56% performance / ~173% memory
* FreeSentry: 높은 메모리 오버헤드

== [[Conclusion]] ==
FPN은 기존 Pointer Nullification의 핵심 병목이었던 metadata lookup 비용과 pointer registration를 Corased-grained block-based region search로 변경하여 문제를 해결하였다. 그결과, 낮은 성능 및 메모리 오버헤드를 가져올 수 있었다. 논문의 몇몇 가정은 동의하기 힘든 부분도 있었지만, "E.g., Page 5, "ALthough scanning entire blocks during nullification may introduce additional performance overhead, deallocations occur infrequently in most applications", [[BUDAlloc: Defeating Use-After-Free Bugs by Decoupling Virtual Address Management from Kernel|BUDAlloc]]과 [[SwiftSweeper]]를 평가에 반영하였기 때문에 매우 높은 점수를 주고 싶다.

Minor comments:

# Buffer information이 설명없이 그림에만 나와서, 알고리즘을 이해하는데 조금 어려웠다.

Major comments:

# Deallocation frequency가 낮기 때문에 Free성능이 병목이 되지 않는 다고 주장하고 있지만, 이 부분에 대한 명시적인 증거가 필요해 보인다. 추측해 보건데, Deallocation frequency가 낮은 것이 아니라, 단순히 Pointer tracking이 Deallocation시의 Overhead를 감수할만큼 더 많이 Overhead를 줄인 것으로 추측된다.
# Performance overhead관점에서 보았을 경우, FPN은 Pointer nullification의 단점인 Overhead를 확실히 많이 끌어 올린 것은 맞지만, 기존의 FFmalloc과 같은 논문과 비교하여 아직 부족한 부분이 있다. Pointer nullification을 좀더 빠르게 만들 수 있는 방법으로, Block tracking 내부적으로 Hash를 이용하는 방법이나, 아니면 LLVM컴파일러의 도움을 받는 부분도 탐색하면 좋을 것 같다는 생각이 든다.

파일:NDSS 2026 FPN Figure 4.png

2026-03-18T04:56:12Z

Ahn9807:

Diagram of FPN and comparisons of pointer registrations between previous PN methods and FPN. To illustrate the points-to relationships more clearly, (a) presents two conceptual views of memory (overlapping with each other): a zoomed-in view highlighting the heap region that heap pointers reference, and a full-memory view showing where these pointers may be stored.

파일:NDSS 2026 FPN Figure 2.png

2026-03-18T03:54:09Z

Ahn9807:

NDSS 2026 FPN Figure 2

대문

2026-02-06T14:11: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>

<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++)
<div class="home-card__header" style="font-size:200%">

</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-02-06T14:10:56Z

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>

<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++)
<div class="home-card__header" style="font-size:200%">

</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>
---!>

Evaluating the Effectiveness of Memory Safety Sanitizers

2026-02-03T13:34:54Z

Ahn9807: 새 문서: {{Paper|title=Evaluating the Effectiveness of Memory Safety Sanitizers|conference=IEEE Symposium on Security and Privacy (SP)|year=2025|author=Emanuel Q. Vintila Technical University of Munich emanuel.vintila@tum.de Philipp Zieris Fraunhofer AISEC philipp.zieris@aisec.fraunhofer.de Julian Horsch Fraunhofer AISEC julian.horsch@aisec.fraunhofer.de}} 분류: IEEE S&P == 개요 == 기존의 다양한 Memory sanitizer들은 성능으로는 Evlauation결과를 보여주지만...

{{Paper|title=Evaluating the Effectiveness of Memory Safety Sanitizers|conference=IEEE Symposium on Security and Privacy (SP)|year=2025|author=Emanuel Q. Vintila Technical University of Munich emanuel.vintila@tum.de Philipp Zieris Fraunhofer AISEC philipp.zieris@aisec.fraunhofer.de Julian Horsch Fraunhofer AISEC julian.horsch@aisec.fraunhofer.de}}

[[분류: IEEE S&P]]

== 개요 ==
기존의 다양한 Memory sanitizer들은 성능으로는 Evlauation결과를 보여주지만 Bug detection capabilities는 Evaluation에서 간과하고 있다. 이 논문은 MSET이라는 Memory safety sanitizer들의 Bug detectabilities를 측정하는 툴을 만들어거 기존의 Sanitizer들의 Bug detectabilities를 다양한 Metric들을 통해서 정량분석 하였다. 이를 통하여 기존의 시스템들이 개념적인 이론은 제공하고 있지만 잘못된 혹은 불충분한 Implementation으로 제대로 동작하지 못하고 있음 또한 알아내었으며, 후속 연구들의 편의를 도모하기 위해서 Open source화 하였다.

== Motivation & Importance ==
Memory safety는 중요하고 그중에서 특히 Spatial safety bug를 잡는 Sanitizer들은 계속 해서 연구되어지고 있다. 그러나 아직 Memory sanitizer의 버그 검출 성능을 spatial safety버그 분야에서 제대로 측정할 수 있는 Metric(성능 지표)는 아직 정립되어 있지 않았다.

== Main Idea ==
Memory Sanitizer Evaluation Tool (MSET)이라는 툴을 개발하여서, 기존 Memory Sanitizer들의 연구를 분석하여 결과를 비교하였다.

== Design ==

== Result ==

== [[Conclusion]] ==

분류:LLVM

2026-01-19T10:20:33Z

Ahn9807: 새 문서: 분류: 컴파일러

[[분류: 컴파일러]]

LLVM

2026-01-19T10:19:46Z

Ahn9807: 새 문서: 분류: 오픈소스 프로젝트 분류: LLVM == 개요 == LLVM(Low Level Virtual Machine)은 모듈화된 구조를 가진 오픈소스 컴파일러 인프라 프로젝트이다. 특정 프로그래밍 언어에 종속되지 않고, 공통의 중간 표현(IR, Intermediate Representation)을 중심으로 다양한 컴파일 최적화와 코드 생성을 수행하는 것이 특징이다. LLVM의 핵심 아이디어는 프로그래밍 언어 → 중간 표현(IR) →...

[[분류: 오픈소스 프로젝트]]
[[분류: LLVM]]

== 개요 ==
LLVM(Low Level Virtual Machine)은 모듈화된 구조를 가진 오픈소스 컴파일러 인프라 프로젝트이다. 특정 프로그래밍 언어에 종속되지 않고, 공통의 중간 표현(IR, Intermediate Representation)을 중심으로 다양한 컴파일 최적화와 코드 생성을 수행하는 것이 특징이다.

LLVM의 핵심 아이디어는 프로그래밍 언어 → 중간 표현(IR) → 최적화 → 대상 아키텍처 코드 생성이라는 단계적 구조이다. 이를 통해 여러 언어가 동일한 최적화 파이프라인을 공유할 수 있으며, 새로운 언어나 하드웨어 아키텍처를 비교적 쉽게 지원할 수 있다.

LLVM은 전통적인 단일 컴파일러가 아니라, 컴파일러를 구성하는 재사용 가능한 라이브러리들의 집합으로 설계되었다. 이로 인해 다양한 컴파일 최적화 기법을 독립적으로 구현·조합할 수 있고, 연구 및 산업 전반에서 폭넓게 활용되고 있다.

== 중간 표현(IR) ==
LLVM은 프로그램을 LLVM IR(Intermediate Representation)이라는 저수준 중간 언어로 표현한다. LLVM IR은 어셈블리어와 유사한 형태를 가지지만, 플랫폼에 독립적이며 정형화된 구조를 갖는다. 모든 소스 언어는 먼저 LLVM IR로 변환된 후, 언어와 무관한 최적화 과정을 거치게 된다.

LLVM IR의 주요 특징은 다음과 같다.
* 정적 단일 할당(SSA, Static Single Assignment) 형식을 사용하여 분석과 최적화가 용이함
* 고급 언어의 구조를 유지하면서도 저수준 최적화가 가능함
* 텍스트 형식(.ll)과 바이너리 형식(.bc)을 모두 지원함

대문

2026-01-19T09:52:18Z

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>

<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++)
<div class="home-card__header" style="font-size:200%">

</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-01-19T09:50:07Z

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>

<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++)
<div class="home-card__header" style="font-size:200%">

</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">
<categorytree mode="pages" namespaces="Main Category">중국 문화와 역사</categorytree>
</div>
<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>
</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-01-15T15:30:06Z

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>

<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++)
<div class="home-card__header" style="font-size:200%">

</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">
<categorytree mode="pages" namespaces="Main Category">중국 문화와 역사</categorytree>
</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-01-15T15:26:55Z

Ahn9807: 봇: 자동으로 텍스트 교체 (-\[\[분류:컴퓨터 공학(\|[^\]]+)?\]\] +)

상위 문서: [[컴퓨터 공학]]<br>
[[:Category:컴퓨터 시스템]]

==개요==
컴퓨터에 있는 모든 것은 bit로 나타내어진다. 컴퓨터는 모든 정보를 bits의 sequence의 형태로 저장한다. <ref>int, char[]</ref>
컴퓨터이렇게 메인 메모리에 bit로 저장된 정보를 CPU가 읽게 하여 이를 register에 저장한 후, 그를 바탕으로 한 연산 결과를 다시 메인 메모리에 저장하는 식으로 작동한다.

==Data Representation==
컴퓨터에서 가장 흔한 데이터의 단위는 Byte이다. Byte는 bit 8개로 구성되며, 그 범위를 [[진법]]으로 나타내면 다음과 같다.
* 2진법: 00000000<sub>2</sub> to 11111111<sub>2</sub>
* 10진법: 0<sub>10</sub> to 255<sub>10</sub>
* 16진법: 00<sub>16</sub> to FF<sub>16</sub>

===Boolean Algebra===
자세한 내용은 [[Boolean Algebra]] 문서를 참조하십시오.

===컴퓨터에서의 수 표현===
자세한 내용은 [[컴퓨터에서의 수 표현]]문서를 참조하십시오.

위와 방식으로 정의된 수는 사칙연산이 가능하다.

==[[Memory]]==
자세한 내용은 [[Memory]] 문서를 참조하십시오.

===[[Register]]===
자세한 내용은 [[Register]] 문서를 참조하십시오.

===[[Array and Struct]]===
자세한 내용은 [[Array and Struct]] 문서를 참조하십시오.

===[[Buffer]]===
자세한 내용은 [[Buffer]] 문서를 참조하십시오.

===[[Cache]]===
자세한 내용은 [[Cache]] 문서를 참조하십시오.

===[[Dynamic Memory Allocation]]===
자세한 내용은 [[Dynamic Memory Allocation]] 문서를 참조하십시오.

==[[Assembly]]==
자세한 내용은 [[Assembly]] 문서를 참조하십시오.

==[[Exceptional Control Flow]]==
자세한 내용은 [[Exceptional Control Flow]] 문서를 참조하십시오.

==[[System-Level I/O]]==
자세한 내용은 [[System-Level I/O]] 문서를 참조하십시오.

==[[Network Programming]]==
자세한 내용은 [[Network Programming]] 문서를 참조하십시오.

==[[Concurrent Programming]]==
자세한 내용은 [[Concurrent Programming]] 문서를 참조하십시오.

==각주==

컴퓨터 네트워크

2026-01-15T15:26:45Z

Ahn9807: 봇: 자동으로 텍스트 교체 (-\[\[분류:컴퓨터 공학(\|[^\]]+)?\]\] +)

상위 문서: [[컴퓨터 공학]]<br>
[[:Category:컴퓨터 네트워크]]

==개요==

==Computer Network와 Internet==
===[[Internet]]===
자세한 내용은 [[Internet]] 문서를 참조하십시오.

===[[network edge]]===
자세한 내용은 [[network edge]] 문서를 참조하십시오.

===[[network core]]===
자세한 내용은 [[network core]] 문서를 참조하십시오.

===[[performance measures in networks]]===
자세한 내용은 [[performance measures in networks]] 문서를 참조하십시오.

==[[Protocol Layers and Their Service Models]]==
자세한 내용은 [[Protocol Layers and Their Service Models]] 문서를 참조하십시오.

===[[Application Layer]]===
자세한 내용은 [[Application Layer]] 문서를 참조하십시오.

===[[Transport Layer]]===
자세한 내용은 [[Transport Layer]] 문서를 참조하십시오.

===[[Network Layer]]===
자세한 내용은 [[Network Layer]] 문서를 참조하십시오.

===[[Data Link Layer]]===
자세한 내용은 [[Data Link Layer]] 문서를 참조하십시오.

==A Day in the Life of a Web Page Request==
해당 문단의 목적은 웹 페이지 하나의 접근하는 데에 얼마나 많은 프로토콜이 사용되는지 알아보고, 프로토콜 스택을 따라가면서 네트워크의 거시적인 작동과정을 살펴보는 것이다.

===Getting Started: DHCP, UDP, IP, and Ethernet===
준영이 노트북을 켜도 [[Switched Local Area Networks#Ethernet|이더넷]] 케이블을 통해 학교의 [[Link-Layer Switches|이더넷 스위치]]에 연결한다고 가정하자. 이 스위치는 학교의 라우터에 연결되어 있으며, 학교의 라우터는 [[Internet#ISP|ISP]]<ref>해당 예시에서는 ahnnet.net이다.</ref>에 연결되어 있다. 해당 예시에서는 ahnnet이 학교의 [[DNS]] 서비스를 제공하므로, DNS 서버는 학교 네트워크가 아니라 ahnnet 네트워크 내에 위치한다. 또한 DHCP 서버는 일반적인 경우처럼 라우터 내부에서 실행되고 있다고 가정한다.

준영의 노트북이 네트워크에 연결되었을 때, IP 주소 없이는 어떤 일도 할 수 없다. 따라서 준영의 노트북이 네트워크와 관련하여 처음 수행하는 작업은,
[[IPv4 Addressing#DHCP|DHCP]] 프로토콜을 실행하여 IP 주소 및 기타 정보들을 DHCP 서버로부터 얻는 것이다. 이를 위해 다음과 같은 일이 일어난다.
# 준영의 노트북 OS가 DHCP 리퀘스트 메시지를 새성하고, 이를 [[UDP]] 세그먼트에 담는다.
#* 목적지 포트는 67(DHCP 서버), 출발지 포트는 68(DHCP 클라이언트)를 사용한다.
#* IP 목적지 주소는 <code>255.255.255.255</code>(브로드캐스트), IP 출발지 주소: <code>0.0.0.0</code>(아직 주소가 없으므로)를 사용한다.
# 이 IP 데이터그램은 이더넷 프레임에 담긴다.
#* [[Switched Local Area Networks#MAC Addresses|MAC]] 목적지 주소는 <code>FF:FF:FF:FF:FF:FF</code>(브로드캐스트)이고, MAC 출발지 주소는 준영의 노트북의 MAC 주소이다.
# 준영의 노트북이 전송한 이더넷 프레임은 스위치로 전달되고, 스위치는 모든 출력 포트(라우터 포함)에 브로드캐스트한다.
# 라우터는 이더넷 프레임을 수신하고, IP 데이터그램을 추출한 후 상위 계층으로 전달한다. IP 목적지가 브로드캐스트 주소이므로, 라우터는 이를 내부 DHCP 서버로 전달한다.
# 라우터 내부의 DHCP 서버는 예를 들어, <code>68.85.2.0/24</code> 주소 범위를 사용할 수 있다고 하자.
#* DHCP 서버는 준영에게 IP 주소를 할당하고, DNS 서버 주소, 기본 게이트웨이 주소, 서브넷 마스크 등을 포함한 DHCP ACK 메시지를 생성한다.
# 이 DHCP ACK 메시지는 UDP 세그먼트/IP 데이터그램/이더넷 프레임으로 캡슐화되며,
#* 출발지 MAC 주소는 라우터 인터페이스의 그것, 목적지 MAC 주소는 준영의 MAC 주소로 설정된다.
# 스위치는 [[Link-Layer Switches#Self-Learning|self-learning을 통해]] 준영의 MAC 주소가 어느 포트에 있는지 알고 있으므로, 해당 포트로만 프레임을 전달한다.
# 준영의 노트북은 DHCP ACK 메시지를 수신하고, 자신의 IP 주소, DNS 서버 주소, 기본 게이트웨이 주소를 저장한다.
이로써 준영의 노트북은 네트워크 초기화를 완료하고, 웹 페이지를 요청하기 위한 준비를 완료했다.

===Still Getting Started: DNS and ARP===
준영이 브라우저에 www.google.com을 입력하면, Google 홈페이지를 띄우기 위한 긴 여정이 시작된다. 먼저 TCP 소켓을 생성하기 위해서는 www.google.com의 IP 주소를 알아야 하며, 이를 위해서 [[DNS]] 프로토콜을 사용한다.
# 운영체제는 DNS 쿼리 메시지("www.google.com" 포함)를 생성한다.
#* 이를 UDP 세크먼트(목적지 포트 번호는 53)에 담고 IP 데이터그램(목적지 IP는 DNS 서버의 그것)에 캡슐화한다.
#* 이 데이터그램을 이더넷 프레임에 담아 게이트웨이 라우터로 전송해야 하는데, 라우터의 MAC 주소는 아직 모르므로 [[Switched Local Area Networks#Address Resolution Protocol(ARP)|ARP 프로토콜]]을 사용한다.
# 준영의 노트북은 IP 주소가 게이트웨이 라우터의 그것이고, 목적지 MAC 주소를 <code>FF:FF:FF:FF:FF:FF</code>로 설정한 ARP 쿼리 메시지를 발송한다.
# 게이트웨이 라우터는 해당 IP가 자기 것임을 인식하고, 자신의 MAC 주소를 담은 ARP 응답 메시지를 전송한다.
#* 준영의 노트북은 이 응답을 수신하여 MAC 주소를 저장하고, DNS 쿼리를 라우터의 MAC 주소로 전송할 수 있는 상태가 된다.

===Still Getting Started: Intra-Domain Routing to the DNS Server===
# 라우터는 프레임에서 IP 데이터그램을 추출하고, 목적지 IP 주소를 확인하여 ahnnet 네트워크로 전달한다.
# Comcast의 라우터들은 자신의 포워딩 테이블([[OSPF|Intra-AS Routing]], [[BGP]] 기반)을 사용해 DNS 서버 방향으로 전달한다.
# 최종적으로 DNS 서버는 요청을 받고, "www.google.com"를 그에 대한 IP 주소로 변환하여 응답 메시지를 UDP 세그먼트, IP 데이터그램, 프레임 순으로 캡슐화해 준영의 노트북으로 되돌려 보낸다.
# 준영의 노트북은 응답을 수신하고 Google의 IP 주소를 획득한다.

===Web Client-Server Interaction: TCP and HTTP===
# 준영의 노트북은 비로소 [[TCP]] 소켓을 만들고, [[HTTP|HTTP GET]] 메시지를 보낼 준비를 한다.
#* 먼저 3-way 핸드셰이크가 수행된다. 이를 위해 [[TCP#Connection Management#TCP: 3-Way Handshaking|SYN 세그먼트]]를 IP 데이터그램/이더넷 프레임으로 캡슐화한 후 게이트웨이 MAC으로 전송한다.
# 이 데이터그램은 학교 네트워크, Comcast, Google 네트워크를 거쳐 www.google.com에 도달한다.
# www.google.com은 TCP SYN을 수신하고 연결 소켓을 만들고, SYNACK을 준영의 노트북으로 전송한다.
# SYNACK은 다시 네트워크를 통해 준영에게 도달하고, TCP 소켓이 연결 상태로 전환된다.
# 이제 HTTP GET 메시지를 생성하여 TCP 세그먼트/IP/프레임으로 캡슐화하여 www.google.com으로 전송한다.
# www.google.com은 리퀘스트를 받고, HTTP 응답 메시지를 생성하며 HTML 페이지 내용을 응답 본문에 담는다.
# 응답 메시지는 경유 네트워크를 통해 준영에게 전달되고, 준영의 브라우저는 HTML을 추출하여 웹 페이지를 렌더링 및 표시한다.

==[[Wireless and Mobile Networks]]==
자세한 내용은 [[Wireless and Mobile Networks]] 문서를 참조하십시오.

==[[Multimedia Networking]]==
자세한 내용은 [[Multimedia Networking]] 문서를 참조하십시오.

==[[Network Programming]]==
자세한 내용은 [[Network Programming]] 문서를 참조하십시오.

==각주==

[[:Category:컴퓨터 네트워크]]

알고리즘 설계와 분석

2026-01-15T15:26:35Z

Ahn9807: 봇: 자동으로 텍스트 교체 (-\[\[분류:컴퓨터 공학(\|[^\]]+)?\]\] +)

[[분류:알고리즘 설계와 분석]]

[[:Category:알고리즘 설계와 분석]]

==개요==
알고리즘이란, 특정한 작업을 수행하기 위한 절차이다. 이에 따라 하나의 알고리즘은 컴퓨터의 종류에 관계 없이 동일한 작업을 동일한 절차로 수행한다. 다만 이를 표현하는 문법이 달라질 뿐이다. 이러한 알고리즘이 잘 작동하기 위해서는 일반적이고(general), 잘 정의된(specified) 문제를 해결할 수 있어야 한다. 이때 잘 만들어진 알고리즘 문제는 그것에 대한 입력으로 주어질 수 있는 인스턴스의 완전한 집합과, 그중 하나의 인스턴스를 입력으로 하였을 때의 정답이 명확하게 설명된다.

예를 들어 정렬(sorting) 문제에 대해 생각해보자. 입력으로는 n개의 수 <math>a_1, ..., a_n</math>으로 이루어진 수열이 주어지며, 이때 출력은 해당 수열을 재배열하여 <math> a'_1 \le a'_2 \le ... \le a'_n</math>이 되도록 하는 것이다. 이때 이러한 작업을 수행하는 알고리즘은 효율적이고(efficient), 정확해야(correct) 한다. 이때 정확함(correctness)에 대한 개념은 많은 알고리즘 문제에서 명확하지 않다. 따라서 알고리즘에서 정확함을 보장하기 위해서는 이를 증명해야 한다. 이에 대한 더 잘 이해하기 위해서는, [[Robot Tour Optimization]] 문제 혹은 [[Selecting the Right Jobs]] 문제에 대한 문서를 참조하면 좋다.

===Demonstrating Incorrectness===
어떤 알고리즘이나 규칙이 항상 최적이라고 주장하기 위해서는, 일반적인 사례에 대해 증명해야 한다. 반대로 이를 부정하기 위해서는 작은 반례 하나만 찾으면 되며, 이는 증명하는 것에 비해서 상대적으로 더욱 쉬운 방법이다. 이러한 반례를 찾는 데에는 아래와 같은 팁들이 존재한다.
# 작은 입력부터 전부 시험해본다.
# 극단적인 예제(아주 크거나 아주 작은 값이 섞여 있는 경우)를 시험해 본다.
# 알고리즘의 각 단계를 밟을 때, 동률(ties)이 존재하는 경우를 살펴본다.<ref>예를 들어 “가장 짧은 interval을 고른다” 했을 때, 길이가 같은 interval이 여러 개 있으면 tie-break 방식에 따라 결과가 달라질 수 있고, 그중 일부는 최적해가 아닐 수 있다.</ref>

===Induction and Recursion===
반례를 찾지 못했다고 해서 알고리즘이 정확하다는 것은 아니다. 엄밀한 증명이 필요하며, 이를 위해서 많이 사용되는 것이 수학적 귀납법이다. 수학적 귀납법은 재귀적인 알고리즘(recursive algorithm)을 증명하는데 자주 활용된다. 이는 아래와 같은 논리 구조를 따른다.
# 기저 사례 (basis case): 가장 작은 입력에 대해 올바름을 보임.
# 귀납 가정 (general assumption): 크기 k 이하에 대해 알고리즘이 맞다고 가정.
# 귀납 단계 (general case): k+1 크기에 대해서도 올바름을 보임.

==알고리즘 분석==
알고리즘의 효율성을 분석하는 것은 매우 중요하다. 이를 위해서 사용하는 도구는 (1) 계산의 RAM 모델(the RAM model of computation)과 (2) 계산 복잡도의 점근적 분석이다. 이때 알고리즘 성능을 평가하기 위해서는 “빅 오(Big Oh)” 표기를 사용한다.

===[[The RAM Model of Computation]]===
자세한 내용은 [[The RAM Model of Computation]] 문서를 참조하십시오.

===[[The Big Oh Notation]]===
자세한 내용은 [[The Big Oh Notation]] 문서를 참조하십시오.

==Data Structures==
어떤 알고리즘에 알맞은 자료 구조를 이식하는 것은 매우 중요한 일이다. 자료 구조 자체는 프로그램의 정당성(correctness)에 영향을 주지는 않지만, 프로그램의 속도에 매우 큰 영향을 준다. 따라서 자료 구조를 이해하는 것은 알고리즘의 설계와 분석을 위해서는 매우 중요하다.

자세한 내용은 [[Data Structures]] 문서를 참조하십시오.

==[[Graph]]==
그래프(Graph)는 알고리즘, 네트워크, 데이터 구조 등 컴퓨터 과학의 여러 분야에서 핵심적인 개념이다.

자세한 내용은 [[Graph]] 문서를 참조하십시오.

==[[Backtracking]]==
[[Backtracking]]에 대한 자세한 설명은 해당 문서를 참조해 주십시오.

==[[Dynamic Programming]]==
[[Dynamic Programming]]에 대한 자세한 설명은 해당 문서를 참조해 주십시오.

==[[NP-Completeness]]==
[[NP-Completeness]]에 대한 자세한 설명은 해당 문서를 참조해 주십시오.

==문제/알고리즘==
* [[Robot Tour Optimization]]
* [[Selecting the Right Jobs]]
* [[Sorting Problem]]
* [[Graph#Graph Traversal|Graph Traversal]]
* [[Topological Sorting]]
* [[Shortest Paths]]
* [[Fibonacci Numbers]]
* [[Binomial Coefficients]]
* [[The Gas Station Problem]]
* [[Edit Distance]]
* [[Vertex Cover]]
* [[Independent Set]]

==각주==

데이터베이스 시스템

2026-01-15T15:26:25Z

Ahn9807: 봇: 자동으로 텍스트 교체 (-\[\[분류:컴퓨터 공학(\|[^\]]+)?\]\] +)

상위 문서: [[컴퓨터 공학]]<br>
[[:Category:데이터베이스 시스템]]

== 개요 ==
Database-management system(DBMS)란 연관된 data들과 그러한 데이터들에 접근하는 프로그램의 집합이다.이를 통해서 사용하기 편리하고 효율적인 환경을 이용자에게 제공한다.
Database System(DB system)은 다수의 유저와 application들에 의해 동시에 접근되는 정보를 관리하도록 설계되었다.
이를 위해 정보 저장을 위한 구조를 정의하거나 정보를 수정하는 메커니즘을 제공한다.
또한 데이터베이스 system은 system crash나 허가되지 않은 접근들에 맞서서 저장된 정보들의 안전성을 담보해야 한다.

이런 데이터베이스 system의 예시는 다음과 같다.
* 기업 정보
** 판매: 소비자, 상품, 구매
** 회계: 가격, 영수증, 자산
** 인적 자원: 직원 정보, 급여

==목적==
데이터베이스 system은 file system을 통한 data관리의 어려움을 타파하기 위해 만들어졌다. 아래와 같은 어려움들이 존재한다.
#Data '''redundancy and inconsistency'''
#* 서로 다른 프로그래머들이 파일과 응용 프로그램을 장기간에 걸쳐 만드므로 다양한 파일들이 서로 다른 구조로 이루어질 가능성이 높다. 또한 응용 프로그램들이 서로 다른 프로그래밍 언어로 짜여질 가능성 또한 존재한다. (inconsistency)
#* 추가로 동일한 정보가 여러 파일에 동시에 존재할 가능성이 있다.
# Difficulty in accessing data
#* 유저가 data에 접근하여 이를 활용하고자 할때 그에 대한 응용 프로그램을 각각 만들어야 한다. 아니면 사용자가 수작업으로 데이터를 가공하여야 한다.
#* 예시로 유저가 60점 이상인 학생들의 목록을 추출할 때, 특정 주소지에 있는 학생들의 목록을 추출할 때, 모두 별개의 프로그램이 필요하다.
# Data isolation
#* 데이터가 여러곳에 분산되어 있고, 파일 형식 등이 다를 수 있으므로 적절한 응용 프로그램의 개발이 어렵다.
# '''Integrity'''
#* 어떤 데이터에 대한 응용 프로그램의 경우는 특정한 제약 조건이 필요하다. (예를 들면 몸무게 > 0 등...) 하지만 새로운 제약이 추가되거나 기존의 제약이 수정될 경우에는 이를 응용 프로그램에 적용하는 것이 어렵다.
#'''Atomicity of Updates'''
#* 컴퓨터가 응용 프로그램의 실행 중 문제가 발생하였을 때 이를 이전의 상태로 복원을 하여야 한다. 이는 데이터베이스의 일관성에 필수적인 요소이다. 예를 들어 은행에 500만원을 입금하였을 때 장애가 생기면 500만원이 입금되었으나 실제로는 계좌에 돈이 입금되지 않는 경우가 생길 수 있으므로 이를 취소해야 한다. 즉 반만 실행되서는 안되며, 완전히 성공하는 경우가 아니라면 아예 데이터베이스의 상태가 바뀌어서는 안된다. 하지만 파일 기반 시스템의 경우 이런 속성을 구현하는 것이 어렵다.
# '''Concurrent access''' by multiple users
#* 데이터베이스 관리의 효율성과 속도를 위해서는 다수의 사용자가 동시에 접속할 수 있어야 한다. 하지만 이러한 경우 다음과 같은 문제가 생길 수 있다. 계좌 A의 잔액이 10,000달러인 상황에서 두 명의 은행 직원이 동시에 500달러와 100달러를 인출한다고 가정하자. 두 프로그램이 동시에 실행되면, 두 프로그램이 각각 이전 잔액인 10,000달러를 읽고, 차감한 후 새로운 값을 기록할 수 있다. 이 경우, 최종 잔액은 9,500달러 또는 9,900달러로 잘못 저장될 수 있다.
#* 이러한 문제를 해결하기 위해서는 시스템이 감독 기능을 제공해야 한다. 하지만 기존의 파일 처리 시스템에서는 여러 응용 프로그램들이 사전에 조율되지 않았기 때문에 이를 제공하기가 어렵다.
# '''Security problem'''
#* 사용자는 그 신분에 따라 접근할 수 있는 data의 범위가 달라져야 한다. 예를 들어 학생을 교수의 이름과 이메일 주소는 볼 수 있어도 교수의 연봉 등의 정보에는 접근할 수 없어야 한다. 하지만 파일 관리를 기반으로 데이터베이스를 관리하면 이러한 경우를 통제하기 어렵다.

==View of Data==
데이터베이스 system의 기본적인 목적은 data에 관한 abstract view를 제공하는 것이다. abstract view란 사용자가 data가 어떻게 관리되고 저장되는 지에 대한 지식이 없어도 해당 data에 접근하고 조작할 수 있다는 개념을 의미한다.

===Data Abstraction===
[[파일:ArchitecureOfDBSystem.png|섬네일|An architecture for a database system]]
데이터베이스는 복잡한 데이터 구조를 가지고 해당 데이터베이스 내의 데이터를 표현한다. 하지만 대부분의 데이터베이스 사용자들은 해당 방법에 대한 전문적인 지식이 없기 때문에 개발자들은 여러 단계의 Data Abstraction을 통해 이런 복잡성을 숨긴다. 이를 통해 사용자가 시스템과 상호작용하는 것을 더욱 쉽게 할 수 있다. 이러한 Data Abstraction은 오른쪽 그림과 같이 세가지 수준에서 구현된다.
# '''Physical Level''': 가장 낮은 추상화 수준으로 데이터가 실제로 어떤 방식으로 저장되는지에 대해 기술한다.
# '''Logical Level'''
#* 그 다음으로 높은 수준이지만 Physical Level에 비해 상대적으로 단순한 구조로 데이터베이스에 저장된 데이터가 무엇인지와 해당 데이터들 사이의 관계에 대해서 서술한다.
#*데이터 베이스 관리자는 데이터베이스에 어떤 정보를 저장할지를 결정할 때 논리적 수준의 추상화를 이용한다.
#* physical data independence: 해단 수준에서 사용되는 단순한 구조를 실행시킬 때 복잡한 physical level에서의 구조를 통해서 구현될 수 있음에도, Logical Level과는 독립적이므로 사용자는 이에 대해서 몰라도 된다는 것이다.
#'''View Level'''
#* 가장 높은 수준으로 사용자에게 전체 데이터 베이스의 일부만을 표시한다. 이는 대부분의 데이터베이스 사용자들은 전체의 정보를 필요로 하지 않고 특정 부분만 접근하면 되기 때문이다. 이는 하나의 데이터베이스에 대해 여러 개의 뷰를 제공하여 구현된다. 그리고 이를 통해서 이런 사용자들의 상호작용을 단순화할 수 있다.
#* 논리적 수준은 단순하지만 전체 데이터베이스는 매우 거대하고 다양한 데이터로 이루어져 있으므로 여전히 복잡성이 남아있다.

다음과 같이 record 타입을 다음과 같이 추상적으로 정의한다고 치자.
<pre>
type instructor = record
ID : char(5);
name : char(20);
dept_name : char(20);
salary : numeric(8,2);
end;
</pre>
위의 코드에서는 instructor라는 새로운 record 타입을 정의하며, 해당 자료구조는 이름과 데이터 타입을 가지는 4개의 필드를 가진다.
예를 들어서 char(20)은 최대 20개의 문자로 이루어진 문자열을 의미한다. 또한 numeric(8,2)는 8자리 숫자 중 소수점 이하 2자리까지 표현 가능한 숫자를 의미한다. 또한 다음과 같은 레코드 타입이 존재할 수 있으며, 대학교의 데이터 베이스가 이를 포함할 수 있다.
* department 레코드: dept_name, building, budget
* course 레코드: course_id, title, dept_name, credits
* student 레코드: ID, name(이름), dept_name, tot_cred
이제 이를 바탕으로 Data Abstraction이 어떻게 구현되는지 살펴보자
# Physical Level에서 교수, 학과, 학생의 레코드는 연속적인 바이트 블록으로 표현된다. 하지만 컴파일러는 이러한 수준의 정보를 프로그래머로부터 숨긴다.
# Logical Level에서 각 레코드는 위에서 설명했듯이 type 정의를 통해서 설명되며, 레코드 유형간의 관계 또한 논리적 수준에서 정의된다. 예를 들어서 instructor 테이블의 dept_name 값은 반드시 department table에 존재해야 한다는 것등이 있다. 또한 프로그래밍 언어를 사용하는 프로그래머들은 이 수준에서 작업한다. 또한 데이터베이스 관리자들도 대부분 이 수준에서 작업한다.
#View 수준에서는 컴퓨터 사용자들이 데이터를 다룰때, 데이터 타입과 관련된 상세한 정보(Logical Level)를 숨긴 애플리케이션 프로그램의 형태로 데이터베이스를 접한다. 이 수준에서는 여러 개의 데이터베이스 뷰가 정의되어 사용자는 이러한 뷰 중 일부 혹은 전체를 볼 수 있다. 또한 이를 통해서 특정 사용자가 데이터베이스의 일부에만 접근할 수 있도록 하는 보안 메커니즘을 제공한다. 예를 들어서 학생은 학생의 정보를 볼 수 있지만, 교수이 salary 항목은 볼 수 없다.

==Instances and Schemas==
데이터베이스는 시간이 지남에 따라 정보가 삽입되고 삭제되며 변화한다. 이때 특정 시점에 데이터베이스에 저장된 정보의 모음을 데이터베이스의 instance라고 한다. 반면 데이터베이스의 전체 설계를 데이터베이스 schema라고 한다. 데이터베이스 스키마와 인스턴스 개념은 프로그래밍 언어로 작성된 프로그램과 유사한 방식으로 이해할 수 있다. 데이터베이스 스키마는 프로그램 내의 변수 선언과 이에 따른 타입 정의에 해당한다. 각 변수는 특정 시점에서 하나의 값을 가진다. 특정 순간의 프로그램 내 변수들의 값이 데이터베이스 인스턴스에 해당한다.

====Schema의 종류====
# '''Physical schema''': physical level에서의 데이터베이스 설계를 나타내며, 데이터가 실제로 어떻게 저장되는 지를 설명한다.
# '''Logical Schema''': logical level에서의 데이터베이스 설계를 나타내며, 데이터가 어떻게 구조화되었는 지와 데이터 간의 관계를 설명한다. application 개발자들은 logical schema를 기반으로 코딩한다.
#'''View Schema''': view level에서 여러개의 schema(subschema)를 가질 수 있으며 이를 통해서 '''데이터베이스의 여러 부분을 사용자마다 다르게 보여줄 수 있다.'''
#'''Instance''': 데이터베이스에 실제로 저장된 내용에 해당한다.

==Database Language==
데이터베이스는 Data-Definition Language(DDL)이라는 언어를 제공해 데이터베이스 schema를 지정할 수 있도록 한다. 또한 Data-Manipulation Language(DML)을 제공하여 데이터베이스에 대한 query와 갱신을 가능하도록 한다. 이때 DDL과 DML은 별개의 언어가 아니며, SQL과 같이 단일한 데이터베이스 언어의 일부를 구성한다. SQL은 거의 모든 Relational 데이터베이스 시스템이 사용하는 데이터베이스 언어이다.

===Data Definition Language===
DDL은 정의들의 집합을 이용하여 데이터베이스 schema를 지정하는데 사용된다.
DDL 명령문을 실행하면 출력(table templates)이 생성되며, 이는 data dictionary에 저장된다.
data dictionary는 metadata(DB schema, integrity constraints, authorization)를 포함한다. 이때 data dictionary는 데이터베이스 시스템에서 특별한 유형의 table로 간주되며, 일반 사용자는 이에 접근하거나 수정할 수 없다. 또한 데이터베이스 시스템은 데이터를 읽거나 수정하기 전에 데이터 사전을 참조한다.

===Data Manipulation Language===
DML은 query language라고도 하며, 적절한 데이터 모델에 의해 조직된 데이터를 갱신하거나 접근하는 데 사용되는 언어이다. DML은 기본적으로 두가지로 구분된다.
# '''Procedural(절차적) DML''': 사용자가 필요한 데이터가 무엇인지(What)뿐만 아니라, '''데이터를 어떻게 가져올지(How)도 명시'''해야 한다.
# '''Declarative(선언적) DML''': 사용자가 '''필요한 데이터가 무엇인지(What)'''만 지정하면 되고, 데이터를 어떻게 가져올지는 명시할 필요가 없다.
#* DML 중, 튜플 등의 검색에 해당하는 부분을 쿼리 언어(query language)라고 한다.

===[[SQL|SQL Query Language]]===
[[SQL|'''SQL Query Language''']]는 비절차적이며, 이로인해 사용자는 '''어떤 데이터를 가져올지(What)를 지정'''할 뿐, 데이터를 가져오는 방법(How)은 지정하지 않는다. Query는 하나 이상의 테이블을 입력으로 받아 단일 테이블을 출력한다. 다음 예시를 살펴보자
<syntaxhighlight lang="SQL">
SELECT name
FROM instructor
WHERE dept_name = 'Comp. Sci.';
</syntaxhighlight>
해당 query 명령어는 dept_name이 'Comp. Sci.'인 교수들의 name 속성만 검색하여 결과로 반환한다.

또한 SQL은 '''Turing Comlete한 언어가 아니다.'''(유저에게 입력받기, 디스플레이에 대한 출력, 네트워크를 통한 통신 기능 등을 지원하지 않는다.) 따라서 복잡한 연산이나 논리, 알고리즘등을 구현해야 할 경우 C++, JAVA같은 host language와 함께 사용해야 한다. 이때 SQL을 상위 수준의 언어에서 사용하는 데에는 다음 두가지 방법이 존재한다.
* SQL을 사용하기 위해서 Language Extension을 사용한다.
* API(응용 프로그램 인터페이스)을 통해 SQL을 데이터베이스에 전송할 수 있다.
위 방법을 바탕으로 데이터베이스와 상호작용하는 데 사용되는 프로그램을 Application program이라고 한다.

==[[Data Storage Structures]]==
자세한 내용은 [[Data Storage Structures]] 문서를 참조하십시오.

==[[Indexing]]==
자세한 내용은 [[Indexing]] 문서를 참조하십시오.

==Database Design==
추상적인 데이터 모델에서 실제 데이터베이스 구현으로 전환하는 과정은 두 개의 최종 설계 단계를 거친다.
# Logical Design: 설계자는 추상적으로 존재하는 schema를 몇가지 결정을 통해 실제 데이터베이스 시스템의 구현 데이터 모델로 변환한다.
#* Business decision: 해당 데이터베이스 내에 우리는 어떤 속성을 기록해야 하는가?
#* Computer Science decision: 어떤 relation schema를 가지고 속성들을 다양한 relation schema 사이에서 어떻게 그룹화해야 하는가? (Relation는 속성들의 집합으로 구성된 table을 의미)
#Physical Design: 논리적 설계에서 얻은 데이터베이스 schema를 바탕으로 데이터베이스의 physical layout을 결정해 데이터의 물리적인 저장 방식을 결정한다.

===Design phase===
# 초기 단계: 예상 DB 유저들의 데이터 요구사항을 파악하기
# 두번째 단계: data model을 고르기
#* 선택한 data model을 구체적으로 적용하여 해당 DB의 schema를 정의한다.
#** 이때 완전히 개발된 schema는 해당 사용자의 기능적인 요구 사항들을 가리킨다.
#* 그 외에도 유저가 해당 data에 대해 사용할 operation이나 transaction(작업)들을 정의한다.
# 마지막 단계: abstract한 data model를 바탕으로 DB를 실제적으로 구현하는 것
#* Logical design: DB schema를 결정하여 데이터베이스에서 어떤 relation이 필요하고, 각 속성이 어떻게 배치될 것인지를 설계한다.
#** Business decision: 유저의 요구 사항에 기반하여 어떤 attribute를 기록해야 할지 정하는 것이다.
#** Computer Science decision: 어떤 relation schemas가 필요하고, 각 relation에서 attribute들을 어떻게 분배할 것인지를 결정합니다.
#* Physical design: 논리적 설계에서 정의된 DB 구조를 실제 저장 매체에 어떻게 배치할지 결정하는 단계이다.
이 결정은 데이터의 정규화와 관계 설계를 포함하며, 데이터베이스의 무결성을 유지하면서 효율적인 저장과 검색을 가능하게 만듭니다.

===Design할 때 고려할 점===
DB schema를 설계할 때 우리는 다음 두가지 주요한 pitfall을 주의해야 한다.
* Redundancy: data가 불필요하게 반복될 때를 의미한다.
** 중복된 data를 여러 위치에 저장하면, data를 업데이트할 때 일관성을 유지하기 어려워질 수 있다.(inconsistency)
** 예를 들어, 동일한 정보가 여러 테이블에 저장되어 있을 경우, 하나의 정보가 수정되었을 때 다른 위치에 있는 정보는 업데이트되지 않아 불일치가 발생할 수 있다.
* Incompleteness: 데이터베이스 설계 시 모델링이 어려운 부분이 생기는 경우이다.
** 즉, DB 설계가 비즈니스 요구 사항을 제대로 반영하지 못해 중요한 정보나 관계를 표현할 수 없게 되는 경우이다.
** 잘못된 경우: TakesCourse(ID, course_id, title, dept_name, cedit, sec_id, semester, year, grade)
*** 해당 DB 설계는 새로운 과목을 개설하기 힘들다. 신규 과목은 학생 정보가 존재하지 않기 때문이다.
** 올바른 경우: takes(ID, course_id, sec_id, semester, year, grade) / course(course_id, title, dept_name, cedit)

===Data Models===
데이터베이스의 구조를 뒷받침하기 위해서는 Data Model이 필요하다. 이는 데이터를 설명하고, 데이터 간의 관계와 의미, 그리고 consistency 제약 조건을 정의하는 개념적인 도구들의 집합이다. Data Model에는 대표적으로 다음 예시들이 있다.
# [[Relational Model]]
# [[Entity Relationship Model]](E-R Model): 해당 모델은 entity라고 불리는 기본 객체들과 해당 객체들 간의 관계들의 집합을 통해 data를 나타낸다.
#Semi-structured Data Model
#* 동일한 유형의 개별 data 항목들이 서로 다른 속성 집합을 가질 수 있도록 허용한다.
#* 대표적인 예시로는 XML이 있다.
#Object-Based Data Model
#* 객체지향 프로그래밍의 대두와 함께 개발된 data model이다.
#* 해당 모델은 relatinal model을 캡슐화, 메서드, 객체 식별 개념과 결합하여 확장한 방식이다.

===[[Relational Database Design]]===
자세한 내용은 [[Relational Database Design]] 문서를 참조하십시오.

==Database Engine==
데이터베이스 시스템은 전체 시스템의 각 기능을 담당하는 여러 모듈로 구분된다.
===Storage Manager===
데이터베이스에 저장된 low-level 데이터와 application 프로그램과 시스템에 전송되는 query들 사이의 인터페이스를 제공하는 프로그램이다.
이는 다음의 작업을 담당한다.
# OS file manager와의 상호작용
#* 이는 데이터베이스 시스템은 디스크와 메모리 간 데이터 이동을 최소화할 수 있도록 데이터를 구조화해야 하기 때문이다.
# 데이터를 효율적으로 저장하고 출력하고 갱신하기
Storage manager는 다음 요소들을 포함한다.
* Authorization and integrity manager
* Transation manager
* File manager
* Buffer manager
Storage manager는 다음 자료구조들을 주로 활용한다.
* Data file: 데이터베이스 자체를 저장함
* Data dictionary: 데이터베이스의 구조에 대한 정보를 포함하는 metadata를 저장함
* Indices: 특정한 값을 가지는 데이터 항목에 대한 포인터를 제공하는 인텍스를 통해 해당 항목에 대한 빠른 접근을 제공함

===Query Processor===
질의 처리기는 데이터베이스 시스템이 시스템이 데이터를 쉽게 접근하고 효율적으로 처리할 수 있게 한다. 이를 통해서 사용자가 View 수준에서 데이터를 다룰 수 있도록 한다. 이는 Logical 수준에서 비절차적인 언어로 작성된 query와 갱신 요청을 physical 수준에서 실행할 수 있는 최적의 연산 순서로 변환하여 구현된다. 이는 다음과 같은 요소들을 통해서 구현된다.
[[파일:QueryProcessing.png|섬네일|Query Processing]]
* DDL interpreter: DDL 명령어들을 해석하고 data dictionary에 정의들을 기록한다.
* DML compiler: query 언어로 되어있는 DML 명령어들을 query evaluation engine이 이해할 수 있는 low level의 명령어로 된 evaluation plan으로 번역한다.
** DML compiler는 query 최적화를 수행한다. 이를 통해서 여러 plan으로부터 가장 효율적인 evaluation plan을 선택한다.
* Query evaluation engine: DML complier에 의해 만들어진 low level 명령어를 실행한다.
Query Processors는 다음과 같은 과정을 통해서 Query Processing을 진행한다.
# Parsing and translation
# Optimization
# Evaluation

===Transaction Management===
Transaction이란 일련의 데이터 접근 작업을 데이터베이스 application의 함수를 통해 하나의 단위로 묶어 처리하는 것이다. Transaction Management는 Transaction이 완전히 실행(Commit)되거나 전혀 실행되지 않도록(Rollback) 보장한다. 이를 통해서 데이터베이스가 일관적인 상태를 system failure에도 불구하고 유지하도록 한다.

또한 Concurrency control manager는 동시적인 Transaction 사이에서의 상호작용을 스케쥴링하여 데이터베이스의 일관성을 유지한다. 이를 통해서 Transaction 실행 중 시스템 오류나 동시 접근(concurrent access) 문제를 신경쓰지 않도록 해준다.

==Database and Application Architecture==
[[파일:Architecture.png|가운데|섬네일|435x435픽셀|System Structure]]
System Structure 그림은 다양한 유저들이 데이터베이스와 어떻게 상호작용하는지, 그리고 데이터베이스 내의 다양한 여러 요소들이 어떻게 서로 연관되어 있는지를 나타낸다. 데이터베이스의 아키텍쳐는 다음 네가지로 구분된다.
# Centralized Databases: 하나 또는 몇개의 코어로 이루어진 공유 메모리 시스템
#* 모든 데이터와 처리 작업이 하나의 중앙 서버에서 이루어진다. 이 아키텍처는 작은 규모의 시스템에서 사용되며, 모든 데이터와 작업이 중앙에서 관리된다.
# Client-Server: 하나의 서버 머신이 여러 클라이언트 머신을 대신하여 작업을 실행한다.
#* 클라이언트는 데이터베이스에 접근하기 위해 서버에 요청을 보내고, 서버는 클라이언트를 대신하여 데이터베이스 작업을 처리한다. 이는 네트워크를 통해 클라이언트와 서버가 상호작용하는 형태이다.
# Parallel Databases: 다음 세가지 방식으로 구현되며, 대규모 데이터와 높은 처리 성능을 요구하는 환경에서 사용된다.
#* Many core shared memory: 여러 프로세서가 공유 메모리 공간을 통해 동시에 작업을 처리한다.
#* Shared disk: 여러 프로세서가 동일한 디스크를 공유하여 데이터를 저장하고 읽는다.
#* Shared nothing: 각 프로세서가 독립적으로 저장 장치와 메모리를 갖고 있으며, 서로 데이터를 공유하지 않는다.

===Database Applications===
[[파일:TierArchitecture.png|섬네일|300x300픽셀|Tier Architecture]]
또한 오른쪽의 Tier Architecture 그림은 데이터베이스 application들이 둘 혹은 셋의 부분으로 분할되는 것을 보여준다.
* Two tier architecture
** application이 client machine에 위치하며, 데이터베이스 시스템의 기능을 서버 머신에서 호출한다.
** 이 구조에서는 client와 서버가 직접적으로 데이터베이스 작업을 처리한다.
* Three-tier architecture
** client 머신은 단순히 front end의 역할을 하며 데이터베이스 호출을 직접적으로 호출하지 않는다.
** client는 form interface<ref>사용자가 DB와 상호작용할 수 있도록 도와주는 UI의 한 형태이다.</ref>를 통해 application 서버와 통신한다. 이때 application 서버는 데이터베이스 시스템과 통신하여 data에 액세스할 수 있다.
** 이 아키텍쳐는 보안과 성능 면에서 Two tier 아키텍쳐보다 더 뛰어난 성능을 제공한다.

==Database Users and Administrators==
===Database Users===
데이터베이스 시스템 사용자 유형은 그들이 시스템과 상호작용하는 방식에 따라 네 가지로 구분되며, 각 사용자 유형에 맞는 다양한 사용자 인터페이스가 설계되어 있다.
# Naive users: 단순 사용자에 해당하며, 시스템과 상호작용하는 데 있어 특별한 기술이나 지식이 없는 사용자를 의미한다.
#* 미리 정의된 form interface와 같은 UI를 통해서 데이터베이스에 접근하며, 이를 통해서 데이터베이스에 접근하여 생성된 정보를 확인할 수 있다.
# Application Programmers: Application 프로그래머들에 해당하며 이들은 여러 도구들을 통해 UI를 개발하는 역할을 한다.
# Sophisticated users: 프로그램을 작성하지 않고도 시스템과 상호작용하는 사람들이다. 대신, 데이터베이스 query 언어나 데이터 분석 소프트웨어와 같은 도구를 사용해 데이터베이스에 접근한다.

===Database Administrator===
Data와 그에 대한 접근하는 프로그램들을 관리하고 통제하는 것은 DBMS를 사용하는 주요한 이유이다. 이런 DBMS에 대한 중앙 control를 가지고 있는 사람을 Database Administrator(DBA)라고 한다. DBA의 권한은 다음과 같다.
# Schema 정의: DDL에서 데이터 정의 명령을 실행하여 원래의 데이터베이스 schema를 생성한다.
# Storage structure과 접근 방식 정의: 데이터의 physial organization 및 indices를 생성하는 데 필요한 매개변수를 정의한다.
# Schema와 physical-organization의 수정: organization의 수정이 요구받을 때 혹은 성능 향상을 위해 schema 및 physical organizaion을 변경
# 데이터 접근에 대한 권한 승인
# 일상적인 유지관리
#* 데이터베이스의 주기적인 백업
#* 정상적인 운영을 위해 충분한 디스크 공간을 확보하고, 필요한 경우 디스크 공간을 업그레이드
#* 데이터베이스에서 실행 중인 작업을 모니터링

==각주==

[[:Category:데이터베이스 시스템]]

계산 이론 개론

2026-01-15T15:26:15Z

Ahn9807: 봇: 자동으로 텍스트 교체 (-\[\[분류:컴퓨터 공학(\|[^\]]+)?\]\] +)

[[분류:계산 이론 개론]]

[[:Category:계산 이론 개론]]

==개요==
해당 문서에서는 기계적 계산(machine computation)에서 등장하는 추상적인 개념들을 소개한다. 이를 위해 다루는 주제는 유한 오토마타(finite automata), 정규 표현식(regular expressions), 형식 언어(formal languages) 등을 포함한다.

==[[Logic and Proofs]]==
수학적 명제(Assertion)의 구조에 익숙해지기 위해서는 명제 연결자(Propositional connectives)와 수량자(Quantifier) 등의 개념에 익숙해져야 한다. 또한 어떤 명제가 주어졌을 때, 이를 바탕으로 다른 명제를 증명하는 구조 역시 중요하다. 이러한 개념과 구조 등은 [[Logic and Proofs]] 문서에 자세히 설명된다.

==Mathematical Objects==
수학적인 명제혹은 주장들은 각종 수학적인 객체들에 대한 문장이나 진술로 해석될 수 있다. 따라서 수학적인 객체에 대한 이해는 매우 중요하며, 이에 따라 해당 문단에서는 각종 수학적 객체들에 대해 설명한다.
* [[Sets]]: 순서가 없는 객체들의 모임을 의미한다.
* [[Functions and Relations|Functions]]: 입력이 주어지면 이에 따라 출력을 내는 "블랙박스"로 이해할 수 있다.
* [[Functions and Relations|Relations]]: 어떤 객체 혹은 객체의 쌍에 대해 "참/거짓"을 판별하는 속성을 의미한다.
* [[Sets#Derived Constructions|Ordered Pairs and Tuples]]: 순서가 정해진 객체들의 모임을 의미한다.
* [[Natural Numbers]]: 0, 1, 2, 3, … 같은 기본적인 수 체계이다.

==[[Finite Automata]]와 [[Regular Languages]]==
[[Finite Automata|Finite Automaton]]<ref>단수형이 automaton, 복수형이 automata이다.</ref>은 유한한 메모리를 가진 단순한 계산 장치를 수학적으로 모델링한 것이며, FSM(Finite State Machine)의 가장 기본적인 형태이다. 이는 단순한 계산 장치이며, "유한 메모리"이기 때문에 무한한 기억이나 복잡한 연산이 불가능하고, 오직 현재 상태와 입력에 따라 동작만 결정된다는 특징이 있지만, 다양한 활용 분야를 가지고 있다.

자세한 내용은 [[Finite Automata]] 문서를 참조하십시오. 또한 finite automata를 이용하면, [[Regular Languages]]를 정의할 수 있다. Regular languages와 관련된 개념으로는 아래의 것들이 있다:
* [[Languages]]
* [[Regular Expressions]]
* [[Generalized NFA]]
* [[Grammars]]
* [[Nondeterministic Finite Automata]]
* [[Chomsky Normal Form]]
* [[CYK Algorithm]]
* [[Pushdown Automaton]]
* [[Pumping Lemma]]

==[[Turing Machines]]==
튜링 머신(Turing Machine)은 계산의 본질을 단순한 모델로 표현한 이론적 컴퓨터 모델이다. 튜링 머신은
모든 계산 가능한 것을 정의하는 최초의 이론적 모델로서 현대 컴퓨터의 이론적 토대를 마련했다. 또한 , 튜링 머신을 통해 계산 가능성의 한계를 증명하고, 어떤 언어의 능력을 평가하는 '튜링 완전성' 개념의 기반이 되었다.

[[Turing Machines|튜링 머신(Turing Machine)]]에 대한 자세한 설명은 해당 문서를 참조해 주십시오.

==각주==

Vertex Cover

2026-01-15T15:26:05Z

Ahn9807: 봇: 자동으로 텍스트 교체 (-\[\[분류:컴퓨터 공학(\|[^\]]+)?\]\] +)

[[분류:알고리즘 설계와 분석]]

상위 문서: [[알고리즘 설계와 분석#문제/알고리즘|알고리즘 설계와 분석]]

==개요==
Vertex Cover 문제는 아래와 같은 정의를 가진다.
입력: 그래프 <math>G=(V,E)</math>, 정수 <math>k</math>
질문: 최대 <math>k</math>개의 정점만 선택해서 모든 간선이 적어도 하나의 선택된 정점에 닿도록 만들 수 있는가?
해당 문제는 3-SAT <math> \rightarrow</math> Vertex Cover reduction을 통해서 Vertex Cover가 NP-Complete임을 보일 수 있다.
이때 Vertex Cover의 complement는 [[Independent Set]]이다.

==각주==

Turing Machines

2026-01-15T15:25:55Z

Ahn9807: 봇: 자동으로 텍스트 교체 (-\[\[분류:컴퓨터 공학(\|[^\]]+)?\]\] +)

[[분류:계산 이론 개론]]

상위 문서: [[계산 이론 개론# Turing Machines|계산 이론 개론]]

==개요==
튜링 머신(Turing Machine)은 계산의 본질을 단순한 모델로 표현한 이론적 컴퓨터 모델이다. 튜링 머신은 모든 계산 가능한 것을 정의하는 최초의 이론적 모델로서 현대 컴퓨터의 이론적 토대를 마련했다. 또한 , 튜링 머신을 통해 계산 가능성의 한계를 증명하고, 어떤 언어의 능력을 평가하는 '튜링 완전성' 개념의 기반이 되었다.

==Basic Concepts of Turing Machines==
튜링 머신의 핵심적인 구성요소는 Control unit, Tape, Read/Write Head이다:
# Control unit: Control unit은 유한한 상태 집합 Q 중 하나의 상태에 머물며 작동한다.
#* 현재 상태를 기억하고 다음 동작을 결정하는 역할을 한다.
# Tape: 무한히 긴 1차원 테이프이며, 칸에는 하나의 기호(symbol)를 쓸 수 있다.
#* 이때 사용할 수 있는 기호들의 집합을 테이프 알파벳<math>(\Gamma)</math>이라고 한다.
# Read/Write Head: 한 번에 한 칸씩 왼쪽(L) 또는 오른쪽(R)으로 이동하면서, 현재 칸의 기호를 읽거나 바꾼다.
튜링 머신은 위의 구성 요소를 바탕으로 유한한 개수의 명령(전이 함수, transition function)을 따라서 작동한다.

===Mathematical Formalization===
튜링 머신은 아래와 같은 7-튜플(<math>Q, \Sigma, , \Gamma, \delta, q_0, q_{accept}, q_{reject}</math>)을 통해서 정의된다:
# <math>Q</math>: 상태들의 유한 집합(states)
# <math>\Sigma</math>: 입력 알파벳 (input alphabet)<ref>이때 공백 문자는 포함하지 않는나.</ref>
# <math>\Gamma</math>: 테이프 알파벳 (tape alphabet), <math>\Sigma \in \Gamma, \textvisiblespace \in \Gamma</math><ref><math>\textvisiblespace</math>는 공백 문자를 의미한다.</ref>
# <math>\delta</math>: 전이 함수(transition function)이며, 아래와 같은 형식이다:<br><math>\delta: Q\times\Gamma\rightarrow Q\times\Gamma\times\{L,R\}</math>
# <math>q_0</math>: 시작 상태(start state)
# <math>q_{accept}</math>: 받아들이는 상태(accept state)
# <math>q_{reject}</math>: 거부 상태(reject state)<ref>단, <math>q_{accept}\neq q_{reject}</math>를 만족한다.</ref>
튜링 머신의 전이 함수를 풀어 설명하면, 아래와 같은 형태이다:
“만약 현재 상태가 q이고, 테이프에서 기호 a를 읽었다면,
이를 기호 b로 바꾸고, 머리를 L 또는 R로 한 칸 이동한 뒤, 상태를 r로 바꿔라.”
즉, 명령은 (q, a) → (r, b, L/R)과 같이 정의된다고 할 수 있다.

튜링 기계의 형식적 정의는 사람마다 약간씩 다를 수 있다. 예를 들어, reject 상태를 따로 두지 않고 accept 상태 만을 정의하고 나머지는 자동으로 reject로 간주하기도 한다. 또한 테이프의 왼쪽 끝 표시(left-end marker)를 따로 두어 기계가 더 이상 왼쪽으로 이동하지 않도록 제한하기도 하기도 한다. 해당 위키에서 참조하는 Michael Sipser의 『Introduction to the Theory of Computation, Third Edition』에서도 아래와 같이 추가적인 정의를 추가한다:
"어떤 구성 <math>(u,q,v)</math>에서 <math>q\in \{q_{accept},q_{reject}\}</math>일 때, 반드시 하나의 후속 구성(successor configuration)을 가진다."
이는 모호하지 않은(결정적) 동작을 보장하여 결정적 튜링 머신(Deterministic Turing Machine)을 전제로 하기 위한 것이다.

==Configurations of Turing Machines==
튜링 머신에서의 구성(Configuration)이란 튜링 머신의 현재 상태 전체를 나타내는 한 단위 상태이다. 이는 아래와 같이 정의된다:
<math>(u,q,v)</math>
이때 <math>q \in Q</math>는 현재 튜링 머신이 위치한 상태를 나타낸다. 또한 <math>u \in \Gamma*</math>는 헤드의 왼쪽에 있는 테이프 내용을, <math>v\in \Gamma^+</math>는 헤드의 오른쪽에 있는 테이프 내용을 의미한다. 예를 들어 <math>(u,q,v)= (101, q_3, 0\textvisiblespace\textvisiblespace\textvisiblespace)</math>와 같이 구성이 주어지면, 현재 상태는 <math>q_3</math>이며, 테이프 왼쪽에는 "101"이, 오른쪽에는 "0"과 공백이 있다는 것을 의미한다. 이때 공백은 테이프 위에서 아무것도 적혀 있지 않은 칸을 의미하며, 입력 이외의 칸을 나타내기 위해 사용하는 심볼이다. 이때 중요한 것은 오른쪽 끝의 공백은 몇 개가 있든 동일한 구성으로 간주한다. 이는 아래와 같이 나타낼 수 있다:
<math>(u,q,v\textvisiblespace^n)=(u,q,v\textvisiblespace^m) for\,\, n,m\ge 0</math>
이는 튜링 기계가 “무한히 많은 빈 칸”을 상정하므로, 불필요한 공백 개수는 의미가 없기 때문이다.

아래 표는 튜링 머신이 계산을 시작하거나 끝내는 특수 상태들을 열거한 것이다:
{| class="wikitable"
|+
!구성 유형
!형태
|-
|시작 구성 (Start configuration)
|<math>q_0w</math>
|-
|Accept 구성 (Accepting)
|<math>uq_{accept}v</math>
|-
|Reject 구성 (Rejecting)
|<math>uq_{reject}v</math>
|}
이때 어떤 튜링 머신 M이 <math>w</math>를 accept한다고 하는 것은 아래 조건들을 만족하는 구성열(sequence)이 존재할 때이다:
# <math>C_1=q_0w</math>
# 중간의 <math>C_i</math>들은 accept/reject가 아닌 일반 상태
# 각 <math>C_i</math>는 <math>C_{i+1}</math>을 yield함
# 마지막 <math>C_k</math>는 accepting configuration
즉, <math>C_1 \Rightarrow C_2 \Rightarrow \cdots \Rightarrow C_k</math>이고, <math>C_k</math>가 accept 상태에 도달하면 문자열 <math>w</math>는 accept된다.

===The Yields Relation===
튜링 머신이 한 단계에서 다음 단계로 이동하는 규칙은 <math>\delta</math>와, 해당 튜링머신의 구성을 통해 정의된다. 예를 들어,
Configuration <math>C_1</math> yields <math>C2</math>
는 주어진 튜링 머신의 상태가 단 한번의 동작으로 <math>C_1</math>에서 <math>C_2</math>로 바뀐다는 것을 의미한다. 이때, 이 yield 관계(relation)는 전이함수 <math>\delta</math>에 의해서 결정된다. 이때 yield 관계는 아래와 같이 구분된다:
# 왼쪽으로 이동 (Move Left)
#* <math>q_ibv</math> yields <math>q_jcv,\,\,if\,\, \delta(q_i,b)=(q_j,c,L)</math><ref>테이프의 맨 왼쪽에서 왼쪽으로 가려는 경우(즉, 왼쪽이 없음)를 의미한다.</ref>: 단순히 머리 위치를 그대로 두고, 공백을 유지한다.
#* <math>uaq_ibv</math> yields <math>uq_jacv,\,\,if\,\, \delta(q_i,b)=(q_j,c,L)</math>: <math>b</math>를 <math>c</math>로 바꾸고 왼쪽으로 이동하여 왼쪽 기호 <math>a</math> 위로 헤드를 옮긴다.
# 오른쪽으로 이동 (Move Right)
#* <math>uaq_ib</math> yields <math>uacq_j\textvisiblespace,\,\,if\,\, \delta(q_i,b)=(q_j,c,R)</math><ref>오른쪽으로 이동했는데, 오른쪽에 아무것도 없는 경우(끝까지 간 경우)를 의미한다.</ref>: 공백(blank)을 새로 하나 추가해야 한다.
#* <math>uaq_ibv</math> yields <math>uacq_jv,\,\,if\,\, \delta(q_i,b)=(q_j,c,R)</math>: <math>b</math>를 <math>c</math>로 바꾸고, 한 칸 오른쪽으로 이동한다.

==Deciders and Languages==
어떤 튜링 머신 <math>M</math>이 decider라고 불리기 위해서는 입력 문자열에서 출발했을 때, 영원히 멈추지 않고 돌기만 하는 경우가 없어야 한다. 즉, 어떤 입력 <math>w</math>에 대해서도 반드시 Accepting 혹은 Rejecting 구성에 도달해야 한다. 이때 모든 튜링 기계가 Decider인 것은 아니며, 어떤 기계는 특정 입력에서 무한 루프에 빠질 수도 있다. 이러한 경우를 recognizer라고 부른다. 이에 따라 튜링 기계가 인식(recognize)하거나 결정(decide)할 수 있는지 여부에 따라 언어(Language)의 종류를 구분할 수 있다. 아래는 이를 정리한 표이다:
{| class="wikitable"
|+
!구분
!정의
!특징
|-
|Turing-recognizable
|어떤 튜링 기계 M이 있어서,
L=L(M) 일 때
|입력이 언어에 속하면 Accept,
속하지 않으면 멈추지 않고 무한 루프 가능
|-
|Turing-decidable
|어떤 Decider M이 있어서,
L=L(M) 일 때
|모든 입력에 대해 반드시 멈추며,
Accept 또는 Reject 중 하나 출력
|}
이때 모든 Decidable 언어는 Recognizable 언어이지만, 그 반대(Recognizable → Decidable)는 성립하지 않는다. 이때 중요한 것은, "모든 정규 언어가 튜링 기계로 결정 가능하다(decidable)"하다는 것이다. 언어를 입력받을 때, 해당 입력이 끝나는 것은 공백(blank symbol)을 통해 판단한다. 즉, 입력을 다 읽고 처음 만나는 blank가 입력의 끝이다.

==Turing Machine Hacking==
튜링 머신은 프로그래밍 언어처럼 다룰 수 있으며, 해당 문단에서는 튜링 머신을 활용한 여러 테크닉에 대해 설명한다. 튜링 머신도 프로그래밍 언어처럼 패턴과 관용구(idiom)가 존재하며, 입력의 끝을 찾거나, 테이프의 처음으로 돌아가거나, 특정 영역을 표시하는 등의 “기본 동작”들을 잘 다루면 복잡한 계산을 구현할 수 있다.

먼저, 입력의 오른쪽 끝을 찾기 위해서는 처음으로 등장하는 <math>\textvisiblespace</math>를 찾으면 된다. 그 이유는 <math>\textvisiblespace</math>이 입력 알파벳에는 포함되지 않지만, 튜링 머신의 테이프 알파벳에는 포함되기 때문이다. 이로 인해 튜링 머신의 테이프에는 입력 문자열이 적혀 있고, 테이프의 끝은 <math>\textvisiblespace</math>으로 채워져 있다.<br>
반대로 테이프의 맨 왼쪽으로 돌아가기 위해서는 첫 단계에서 현재 보고 있는 기호를 기억(finite control)하고,
그 자리를 특별한 마커(symbol)로 바꾼다. 이후 왼쪽으로 계속 이동하다가 그 마커를 만나면 “출발점”을 찾을 수 있다.

테이프의 칸을 “표시(mark)”하는 방법을 확장하면, 테이프 알파벳의 각 기호마다 표시(mark) 여부에 따라 어떤 셀을 “방문했음” 혹은 “처리했음”으로 표시할 때 활용할 수 있다.

이 외에도 표시(mark)를 활용하는 방법으로는 스크래치 영역(scratch) 영역을 임의로 만드는 것이 있다. 예를 들어 프로그래밍에서의 “임시 변수 메모리 영역”을 튜링 머신에서도 활용하기 위해서는 입력의 오른쪽 끝을 찾은 뒤, 그 옆에 특별한 마커를 써서 임시 작업 공간을 확보할 수 있다. 이러한 임시 작업 공간은 필요시 가장 오른쪽으로 가서 해당 마커를 찾아 사용될 수 있다.<br>
스크래치 영역은 마치 호출 스택(call stack)과 같이 활용될 수도 있다. 현재 상태(복귀할 위치)를 스택에 저장하고, 서브루틴의 첫 상태로 점프한 후 끝나면 스택에 저장된 복귀할 위치로 돌아오는 구조를 만들면 된다.<br>
또한 스크래치 영역의 일부를 레지스터 처럼 사용하여 입력의 일부 값을 복사해서 저장하거나, 연산 중간 결과를 보관할 수도 있다.

==Turing Machine Variants==
튜링 머신은 다양한 확장 버전이 존재한다. 이는 아래와 같다:
# Multi-track tape: 표준 TM 테이프의 각 칸이 하나의 기호만 저장한다면, 멀티트랙 TM 테이프는 각 칸이 여러 기호 묶음을 저장한다.
# Two-way infinite tape: 테이프가 오른쪽뿐만 아니라 왼쪽 방향으로도 무한히 뻗어 있다.
# Multiple tapes with independent heads: 테이프 여러 개이며 각각에 대한 헤드가 따로 존재하여 움직인다.
# Nondeterminism: 여러 선택지를 동시에 탐색하는 튜링 머신이다.
이때 중요한 것은 튜링머신을 여러 방식으로 강화(멀티트랙, 양방향 테이프, 여러 테이프, 비결정성)해도 ‘어떤 언어를 인식할 수 있는가 / 결정할 수 있는가’라는 능력은 변화하지 않는다는 것이다. 단지 시간과 공간적인 측면에서의 효율성만 달라진다.

==TMs as Language Enumerators==
튜링머신은 입력을 받아 accept/reject하는 방식으로 언어를 정의할 수도 있지만, 반대로 “언어의 모든 문자열을 하나씩 출력해 나가는 방식”으로도 언어를 정의할 수 있다. 이러한 방식으로 사용되는 기계를 enumerator라고 한다. 이는 테이프 두개를 사용하여 구성된다:
# 출력 테이프: 오른쪽으로만 움직이며 출력을 하는데에 사용된다. 또한 한번 쓰면 덮어 쓸 수 없다.
# 작업 테이프: 계산을 하는 데에 사용된다.
튜링 머신은 처음에 두 테이프가 모두 비어있을 떄 시작한다. 이때 튜링 머신이 특수기호 # 을 출력테이프에 찍을 때마다 “한 개의 문자열을 다 출력했다”고 간주한다. 즉, 출력 형식은 아래와 같다:
w1 # w2 # w3 # ...
이렇게 나열된 문자열들의 모임이 해당 튜링 머신이이 열거하는 언어이다. 이때 어떤 언어 L이 Turing-enumerable하다는 것은 어떤 튜링 머신이 L의 모든 가능한 문자열을 출력해낼 수 있다는 것을 의미한다. 이때 중요한 것은 Turing-recognizable과 Turing-enumerable은 동치라는 것이다. 또한 아래의 관계가 성립한다:
Turing-decidable <math>\subset</math> Turing-recognizable <math>\equiv</math> Turing-enumerable
이는 decider는 모든 입력에서 halt하는 반면, recognizer는 정답이 맞으면 halt하고 accept, 틀리면 halt하거나 loop해도 되기 때문이다. 즉, decider는 모든 입력에 대해 항상 halt하므로 recognizer의 조건을 더욱 강하게 충족한다.

==Using TMs to Compute Functions==
튜링머신은 단순히 “accept or reject”만 하는 기계가 아니다. 튜링머신은 입력이 주어지면 어떤 출력을 만들어내는 계산 장치로도 사용할 수 있다. 예를 들어, 함수 <math>f(w)=x</math>를 계산하기 위해서는 입력 <math>w</math>를 어떤 튜링 머신 M을 사용하여 출력 <math>x</math>를 얻으면 된다. 하지만 TM이 모든 입력에서 반드시 halt하는 것이 아니기 때문에
튜링머신이 계산하는 함수는 부분 함수(partial function)일 수 있다. halt하지 않으면 튜링머신이 무한루프에 빠지고, 이는 출력이 만들어지지 않는 상황이기 때문이다.

일반적인 함수 <math>f</math>는 아래의 조건을 만족하는 <math>\Sigma*\times\Sigma*</math>의 부분집합으로 정의된다:
<math>(w,x)\in f\land (w,y)\in f\rightarrow x=y</math>
이때 total function <math>f</math>는 모든 입력 <math>w</math>에 대해서 어떤 출력 <math>x</math>가 존재하는 것으로 정의된다.

튜링머신에 의해서 계산되는 함수 <math>f(M)</math>은 아래와 같이 정의된다:
<math>f(M)=\{(w,x)|M</math>이 입력 <math>w</math>를 주었을 때 halt하고 accept했으며, accept 순간 테이프의 내용이 <math>x</math>인 경우<math>\}</math>
즉, <math>f(M)</math>이 <math>w</math>를 입력으로 받아 accept 상태로 멈추고 그 순간 테이프가 <math>x</math>를 담고 있다면 그때 <math>(w,x)</math>가 <math>f(M)</math>의 입력/출력 쌍이 된다는 것이다. 하지만 튜링머신에서 출력 <math>x</math>가 <math>x\notin \Sigma*</math>이라면 이는 유효한 입력/출력 쌍이 되지 않는다. 이때 <math>f</math>가 어떤 튜링머신 <math>M</math>에 의해서 partial function이라면 <math>f</math>는 computable partial function이라고 한다. 또한 <math>f</math>가 total이고, 튜링머신이 모든 입력에서 halt해 결과를 준다면 <math>f</math>는 total computable function이다.

==Church-Turing Thesis==
Church-Turing Thesis는 어떤 합리적인(reasonable)” 알고리즘이든, 그것이 언어 L을 결정하거나 인식하거나 함수를 계산하는 방식이든, 결국 그 능력은 튜링머신으로 표현 가능한 계산 능력과 완전히 동일하다는 것을 의미한다. 이때 “Reasonable"이라는 말의 의미는 아래와 같다:
# 계산 기계는 유한한 규칙으로 동작하고, 필요한 만큼 확장 가능한 저장소(메모리)를 사용한다.
#* 실제 컴퓨터, RAM, 종이와 연필, 계산기 등 모두가 이에 해당한다.
#* 튜링머신도 테이프가 무한하다고 가정한다.
# 알고리즘은 기본 연산들의 유한한 집합으로 표현될 수 있다.
#* 우리가 짜는 프로그램이든, 사람이 수행하는 알고리즘이든 “유한한 규칙, 단계, 연산”으로 되어 있어야 한다는 것을 의미한다.
#* 튜링머신도 유한한 상태·전이 표로 정의된다.
# 각 기본 연산은 유한 시간 안에 수행되며 유한한 저장을 사용한다.
#* 무한한 계산 단계를 한 번에 수행하는 “초능력” 연산은 허용되지 않는 다는 것을 의미한다.
#* 튜링머신도 한 스텝씩 움직이며 작동한다.
# 각 기본 연산의 효과는 예측 가능해야 한다.
#* 같은 상태·조건에서 항상 같은 결과를 내야하며, 비결정적·무작위적 초능력은 허용되지 않는 다는 것을 의미한다.
#* 튜링머신은 완전히 기계적·결정적 규칙으로 작동한다.
따라서 결론적으로 Church-Turing Thesis에 대해서 설명하면 아래와 같다:
* 언어 L을 어떤 알고리즘이 결정(decide)할 수 있다면 → TM도 할 수 있다
* 언어 L을 어떤 알고리즘이 인식(recognize)할 수 있다면 → TM도 할 수 있다
* 어떤 알고리즘이 어떤 partial function을 계산한다면 → TM으로도 계산 가능
* 어떤 알고리즘이 어떤 total function을 계산한다면 → TM으로도 계산 가능
즉, 컴퓨터로 할 수 있는 계산은 튜링머신으로 할 수 있는 계산과 정확히 동일하다. 이는 "알고리즘" 자체가 엄밀하지 않은 개념이기에 수학적으로 증명되지 않은 명제이지만, 경험적으로 매우 강력하게 지지된다.

==Encoding Objects as Strings==
컴퓨터 이론(특히 decidability/complexity)은 모든 입력을 문자열 형태로 다루기 때문에, [[Nondeterministic Finite Automata |DFA]]나 튜링 머신과 같은 복잡한 “기계”도 문자열 형태로 인코딩해야 한다. 이는 튜링머신은 “입력 테이프”에 문자열만을 읽어 들이며, 컴퓨터 이론에서는 이런 "기계"들을 입력으로 분석하는 문제를 다루기 때문이다. 예를 들어 아래는 DFA의 transition function을 튜플들의 나열로 표현한 것이다.
<math>(q_1\#a_1\#b_1)(q_2\#a_2\#b_2)\cdots(q_n\#a_n\#b_n)</math>
위에서 <math>q_i</math>는 DFA의 상태를, <math>a_i</math>는 입력 심볼을, <math>b_i</math>는 다음 상태를 의미한다. 이때 중간의 <math>\#</math>은 객체를 구분하기 위한 구분자로서 사용되었다. 이를 통해서 튜링머신이 이 문자열을 "읽고 파싱함"으로써 DFA의 구조를 이해하는데 사용할 수 있다. 이때 상태나 입력 심볼이 많아질수록, 알파벳으로 표현하면 길이가 매우 길어진다. 따라서 이를 단순화 하기 위해서 상태/심볼을 이진수로 표현하여야 한다. 예를 들면 아래와 같다:
<math>(q1 \rightarrow 0000)</math>
<math>(a1 \rightarrow 00)</math>
<math>(b1 \rightarrow 0001)</math>
<math>(0000\#00\#0001)</math>
이러한 방식으로 모든 전이함수를 이진수로 인코딩할 수 있다. 이와 같은 방식으로 DFA의 입력 테이프에 올라가는 문자열을 길이 제한 없이 표현하기 위해 입력 문자열도 아래와 같이 인코딩 가능하다:
<math>(00\#01\#10\#00\#00\#11)</math>
이때 기계, 그래프, 정수 등의 어떤 객체 <math>x</math>를 문자열로 나타낸 것을 <math>\langle x\rangle</math>과 같이 표현할 수 있다. 예를 들어, <math>\langle DFA\rangle</math>는 DFA를 문자열로 encode한 것이고, <math>\langle G\rangle</math>은 그래프를 문자열 형태로 나타낸 것이다.

==Decidability and Complexity==
문제의 결정가능성(decidability)<ref>문제가 이론적으로 해결 가능한지의 여부를 의미한다.</ref>에 대해서 고려할 때에는 인코딩의 길이와 방식같은 세부적인 사항이 문제되지 않는다. 이는 입력의 길이와 형식이 문제 풀이의 가능 여부에 영향을 미치지 않기 때문이다. 하지만 문제의 복잡도(complexity)를 고려할 때에는 인코딩의 길이가 큰 영향을 끼친다. 이는 인코딩의 길이가 입력 크기 n에 대해 직접적으로 영향을 미치기 때문이다. 따라서 이 경우에는 엄격하게 binary encoding을 규정해야 한다.

===Relationship between Classes of Languages===
아래는 컴퓨터 이론에서 다루는 언어(문자열 집합)들의 계층 관계를 나타낸 것이다:
Regular <math>\subseteq</math> CFL <math>\subseteq</math> Decidable <math>\subseteq</math> Recognizable <math>\subseteq</math> Other
안쪽일수록 단순한 기계로 인식 가능한 언어이고, 바깥으로 갈수록 더 강력한 계산 모델이 필요하다. 이는 단순히 “복잡성의 차이”가 아니라, 바로 결정 가능성(decidability) 과 직접적으로 연결된다. 언어 클래스가 바깥으로 갈수록 “결정 가능한 것”에서 점점 벗어나기 때문이다. 아래는 각 언어들에 대한 설명이다:
# Regular, Context-Free 언어: 둘 다 결정 가능(decidable)
#* Regular 언어 → DFA/NFA는 항상 결정 가능
#* Context-Free 언어 → CYK algorithm, deterministic PDA 등으로 항상 결정 가능
# Decidable 언어: 모든 입력에서 halt 하는 튜링머신이 있는 언어
#* 따라서 모든 decidable 언어는 알고리즘으로 완전히 판정 가능한 언어들이다.
# Turing-recognizable 언어: 어떤 입력에 대해 halt하지 않고 무한 loop를 돌 수도 있다.
# Recognizable 바깥의 언어들: 이는 더 심각한 수준의 undecidable 언어들이며, 어떤 알고리즘도 해당 언어를 인식조차 못한다.

===Undecidability===
위에서 언급하였듯이, 어떤 언어들은 Turing-recognizable조차 될 수 없는 undeterministic 언어이다. 이는 아래와 같은 논증을 통해 증명될 수 있다:
# 모든 튜링 머신은 유한한 문자열로 인코딩할 수 있는데, 유한 문자열 집합 <math>\Sigma*</math>은 countable이다.
# 언어는 <math>\Sigma*</math>의 부분집합이므로, 부분집합 전체는 <math>\mathcal{P}(\Sigma*)</math>이므로 uncountable하다.
# 따라서 모든 언어 중 대다수는 튜링 머신으로 인식(recognize)조차 할 수 없다.
또한 recognizable이지만 decidable은 아닌 언어들이 존재한다는 것은 계산할 수 있는 것에는 본질적 한계가 있다는 것을 의미한다.

==Universal Turing Machine==
아래와 같은 언어 <math>A_{TM}</math>을 고려해보자:
<math>A_{TM}=\{\langle M, w\rangle|M\,\,\, acept \,\,\, w\}</math>
이러한 언어 <math>A_{TM}</math>은 입력으로 받은 <math>\langle M, w\rangle</math> 튜링 머신 <math>U</math>를 재구성한다. 튜링 머신 <math>U</math>는 <math>M</math>을 <math>w</math>에 대해 시뮬레이션하며, <math>M</math>이 accept/reject하면 <math>U</math>도 이에 따라 accept/reject한다. 물론 <math>M</math>이 무한 루프면 <math>U</math>도 멈추지 않고 무한 루프를 돈다.
이때, 다른 모든 튜링 머신 <math>M</math>을 입력받아 <math>w</math>에 대해 시뮬레이션하는 튜링 머신 <math>U</math>를 Universal 튜링 머신이라고 한다.

===Undecidablity of Universal TM===
이때 <math>A_{TM}</math>은 undecidable하다. 이를 증명하기 위해서는 아래와 같은 decider <math>H</math>가 있다고 가정해야 한다:
입력: <math>\langle M, w\rangle</math>
출력: <math>M</math>이 <math>w</math>를 accept하면 → H accepts
<math>M</math>이 <math>w</math>를 reject하면 → H rejects
<math>M</math>이 loop해도 <math>H</math>는 반드시 accept/reject 중 하나를 출력한다.
하지만 이는 모순을 일으킨다. 또한 아래와 같은 universal 튜링머신 <math>D</math>를 만들어야 한다:
입력: <math>\langle M \rangle</math>
동작: <math>H(\langle M, \langle M\rangle \rangle)</math>을 실행한다.<ref>“M은 자기 자신을 문자열로 인코딩한 입력을 accept하는가?”를 H에게 물어본 것이다.</ref>
출력: <math>H</math>의 답을 뒤집는다.
H가 accept → D는 reject
H가 reject → D는 accept
<math>\therefore\,\,\, D(M)=not \,\,\, H(\langle M, \langle M \rangle \rangle)</math>
즉, <math>D</math>는 "M 자기 자신에 대해 M이 무엇을 하는지"를 무조건 반대로 따라 한다. 이때 <math>D(\langle D \rangle)</math>을 실행하면, 이는 모순을 일으킨다. 먼저 <math>D(\langle D \rangle)=accept</math>이면, <math>H(\langle M, \langle M \rangle \rangle)</math>은 D가 자기 자신을 accept한다고 판단하였으므로, <math>D</math>는 이를 뒤집어 reject해야 하기 때문이다. 이는 모순을 일으키며, <math>D(\langle D \rangle)=reject</math>일 때에도 마찬가지로 모순을 일으킨다. 따라서 <math>H</math>는 실제로 존재할 수 없으며, <math>A_{TM}</math>은 undecidable하다.

이때 <math>D</math>가 decidable하기 위해서는 <math>L(D)</math>와 <math>L(D)</math>의 여집합이 모두 recognizable해야 한다. 이때 <math>A_{TM}</math>은 recognizable하므로, <math>A_{TM}</math>의 여집합은 unrecognizable하다.

===Theorems about Undecidablity===
먼저, Halting 튜링 머신은 아래와 같은 튜링 머신을 의미한다.
<math>HALT_{TM}=\{\langle M,m\rangle|M</math>이 <math>w</math>에서 정지하는 모든 쌍<math>\}</math>
위 튜링머신은 주어진 입력에 대해 튜링머신이 정지하는지를 판단하는 튜링머신이며, undecidable하다.

다음으로 Emptiness 튜링 머신은 아래와 같은 튜링 머신을 의미한다:
<math>E_{TM}=\{\langle M\rangle|M</math>의 언어 <math>L(M)=\empty\}</math>
위 튜링머신은 입력으로 주어진 M이 만드는 언어가 공집합인지를 판단하는 튜링머신이며, undecidable하다.

또한 ALL_CFG 튜링 머신은 아래와 같은 튜링머신을 의미한다:
<math>ALL_{CFG}=\{\langle G\rangle|</math>CFG <math>G</math>가 <math>\Sigma*</math> 전체를 생성한다.<math>\}</math>
위 튜링머신은 입력으로 주어진 문법이 가능한 모든 문자열을 모두 만드는지를 판단하는 튜링머신이며, undecidable하다.

마지막으로, EQ_CFG 튜링 머신은 아래와 같은 튜링머신을 의미한다:
<math>EQ_{CFG}=\{\langle G, H\rangle|</math> 두 CFG <math>G, H</math>가 같은 언어를 생성한다.<math>\}</math>
위 튜링머신은 주어진 문법 G, H가 완전히 같은 언어를 만드는지 판별하는 튜링머신이며, undecidable하다.

==[[Post Correspondence Problem]]==
[[Post Correspondence Problem|Post Correspondence Problem(PCP)]]에 대한 자세한 설명은 해당 문서를 참조해 주십시오.

==각주==

Topological Sorting

2026-01-15T15:25:45Z

Ahn9807: 봇: 자동으로 텍스트 교체 (-\[\[분류:컴퓨터 공학(\|[^\]]+)?\]\] +)

[[분류:알고리즘 설계와 분석]]

상위 문서: [[알고리즘 설계와 분석#문제|알고리즘 설계와 분석]]

==개요==
[[파일:Figure 1. 위상 정렬 예시.png|섬네일|Figure 1. 위상 정렬 예시]]
위상 정렬(Topological Sorting)은 사이클이 없는 방향 그래프(DAG)에 대해서만 가능하다. 이때 위상 정렬이란 모든 간선 (u → v)에 대해, u가 항상 v보다 먼저 나와야 한다는 것을 의미한다. 예를 들어 figure 1은 주어진 왼쪽 그래프의 간선의 방향이 “왼쪽에서 오른쪽”으로 진행되도록 배열하여 오른쪽과 같이 배치된 것을 볼 수 있다.

==Applying Toplogical Sorting==
[[파일:Figure 2. 의류 착용 제약 조건 그래프.png|섬네일|Figure 2. 의류 착용 제약 조건 그래프]]
위상 정렬은 “주어진 제약조건을 만족하면서 해야 할 일들을 어떤 순서로 수행할 것인가?”와 같은 스케줄링(scheduling) 문제에서 매우 자주 사용된다. 예를 들어 figure 2는 옷을 입을 때의 순서에 대한 제약 조건을 그래프로 표현한 것이다. 이를 위상 정렬로 표현함으로서 모든 의류의 올바른 착용 순서를 얻을 수 있다.
[[파일:Figure 3. DNA 패턴 분석.png|섬네일|Figure 3. DNA 패턴 분석]]
예를 들어, DNA 서열 재조합(DNA sequence assembly)에서 figure 3와 같은 상황을 가정하자. DNA를 읽을 때, 전체 서열이 아니라 “부분(fragment)” 단위로 읽으며, 각 조각들을 겹치는 순서대로 이어붙여야 전체 서열을 복원할 수 있다. 이 조각들을 그래프의 노드로 두고, “어떤 조각이 다른 조각보다 왼쪽"이라는 순서 제약을 간선으로 표현하면 DAG가 된다. 이 DAG를 위상 정렬하면, 모든 조각이 일관된 순서로 이어진 완전한 DNA 서열을 얻을 수 있다.

==Topological Sorting via DFS==
위상 정렬은 [[DFS]] 알고리즘을 통해 구현할 수 있다. DFS 중에 Back Edge가 존재하지 않으면, 사이클이 존재하지 않으므로 DAG라는 것을 의미한다. 따라서 DFS로 DAG를 탐색하면서 각 정점의 처리 완료 시점(finished time)을 기록하면, 이 역순(reverse order)이 바로 위상 정렬이 된다. 이는 아래와 같은 구현 원리를 가진다:
# DFS를 수행한다.
# 어떤 노드의 인접 노드 탐색이 모두 끝났을 때<ref>즉, processed = true인 상태이다.</ref> 그 노드를 스택에 push한다.
# 모든 노드에 대해 이 과정을 수행한 뒤, 스택을 뒤집으면 위상 정렬 순서가 된다.
이에 대해 직관적으로 보면, 간선 (x, y)가 있을 때, x의 탐색이 y보다 먼저 시작되므로 x가 y보다 나중에 처리 완료된다는 것이다. 따라서 이에 대한 완료 시점을 역순으로 나열하면 모든 간선이 왼쪽에서 오른쪽 방향이 된다. 이를 좀 더 자세히 살펴보기 위해, 각 간선(x, y)이 어떤 상태에 있는가 분석할 수 있다.
* If y is undiscovered
** y는 아직 방문하지 않아 DFS는 y를 먼저 탐색한다.
** 따라서 y가 먼저 완료되고 x가 나중에 완료된다.
** 위상 정렬에서 x가 y보다 앞에 위치한다.
* If y is discovered but not completed
** y는 아직 처리 중이며, 이에 따라 간선 (x, y)는 back edge이다.
** 이때 back edge는 사이클을 의미하므로, DAG에서는 존재할 수 없다.
* If y is completed
** y의 탐색이 이미 끝났고, 이는 y는 x보다 일찍 완료된 상태라는 것을 의미한다.
** 위상 정렬에서 x가 y보다 앞에 위치한다.
이 세 가지 경우 모두 DAG의 위상 정렬 조건을 만족한다.

===Topological Sorting Implementation===
아래는 DFS를 이용한 위상 정렬의 핵심 구조를 보여주는 코드이다:
<syntaxhighlight lang="c">
void process_vertex_late(int v) {
push(&sorted, v);
}
</syntaxhighlight>
위 코드는 DFS에서 한 정점 v의 모든 인접 노드를 다 탐색하고 난 “후처리 단계(late processing)” 에 실행되는 함수이다. 즉, 정점의 모든 outgoing edge(출발 간선) 이 끝난 시점에 실행되며, v를 sorted 스택에 push한다. 이때 DFS 완료 후, 스택을 뒤집으면 위상 정렬 순서가 된다.

<syntaxhighlight lang="c">
void process_edge(int x, int y) {
int class;
class = edge_classification(x, y);

if (class == BACK) {
printf("Warning: directed cycle found, not a DAG\n");
}
}
</syntaxhighlight>
위는 판단하고자 하는 방향 그래프에서 해당 간선의 종류를 판단하는 함수이다. 이는 해당 그래프에 back edge가 존재하는지 판단하여 그래프가 DAG가 아니라면 이에 대해 경고하는 안전 장치 역할을 한다. 위 함수들을 통해서 아래와 같이 위상 정렬 알고리즘이 구현된다.
<syntaxhighlight lang="c">
void topsort(graph *g) {
int i;
init_stack(&sorted); //위상 정렬 결과를 저장할 스택 초기화

for (i = 1; i <= g->nvertices; i++) {
if (!discovered[i]) {
dfs(g, i);
}
}

print_stack(&sorted); /* report topological order */
}
</syntaxhighlight>

==Kahn’s Algorithm==
아래는 DFS가 아닌, 진입차수(indegree) 를 이용한 Kahn’s algorithm 방식이다.
<syntaxhighlight lang="c">
void toposort(graph *g, int sorted[]) {
int indegree[MAXV+1]; /* indegree of each vertex */
queue zeroin; /* vertices of indegree 0 */
int x, y; /* current and next vertex */
int i, j; /* counters */
edgenode *p; /* temporary pointer */

compute_indegrees(g, indegree);
init_queue(&zeroin);
for (i = 1; i <= g->nvertices; i++) {
if (indegree[i] == 0) {
enqueue(&zeroin, i);
}
}

j = 0;
while (!empty_queue(&zeroin)) {
j = j + 1;
x = dequeue(&zeroin);
sorted[j] = x;
p = g->edges[x];
while (p != NULL) {
y = p->y;
indegree[y]--;
if (indegree[y] == 0) {
enqueue(&zeroin, y);
}
p = p->next;
}
}

if (j != g->nvertices) {
printf("Not a DAG -- only %d vertices found\n", j);
}
}
</syntaxhighlight>
<syntaxhighlight lang="c">
void compute_indegrees(graph *g, int in[]) {
int i; /* counter */
edgenode *p; /* temporary pointer */

for (i = 1; i <= g->nvertices; i++) {
in[i] = 0;
}

for (i = 1; i <= g->nvertices; i++) {
p = g->edges[i];
while (p != NULL) {
in[p->y]++;
p = p->next;
}
}
}
</syntaxhighlight>

==각주==

The RAM Model of Computation

2026-01-15T15:25:35Z

Ahn9807: 봇: 자동으로 텍스트 교체 (-\[\[분류:컴퓨터 공학(\|[^\]]+)?\]\] +)

[[분류:알고리즘 설계와 분석]]

상위 문서: [[알고리즘 설계와 분석#알고리즘 분석|알고리즘 설계와 분석]]

==개요==
기계와 상관없이 독립적으로 작동하는 알고리즘의 설계는 RAM(Random Access Machine)이라고 불리는 가상의 컴퓨터에 의존한다. 이때 해당 컴퓨터의 특징은 아래와 같다.
* 각각의 단순 연산(+, *, –, =, if, call)은 정확히 한 시간 단계(time step)를 소요한다.
* 반복문과 서브루틴은 단순 연산으로 간주되지 않는다.
* 각 메모리 접근은 정확히 한 시간 단계(time step)를 소요한다.
RAM 모델에서 실행 시간은 주어진 문제 인스턴스에서 알고리즘이 수행하는 단계 수를 통해 측정한다. 이때 RAM이 초당 일정한 수의 단계를 수행한다고 가정한다면, 이 연산 계수는 실제 실행 시간으로 자연스럽게 변환된다. RAM은 컴퓨터가 수행하는 방식을 단순화한 모델이다. 이는 너무나 단순화한 나머지 실제로 컴퓨터가 동작하는 방식과는 차이가 있지만, RAM은 실제 컴퓨터에서 알고리즘이 어떻게 성능을 낼지를 이해하는 데 훌륭한 모델이다.

==Best/Worst/Average-Case Complexity==
RAM 모델을 사용하면 주어진 입력 인스턴스에 대해 알고리즘을 실행하여 해당 알고리즘이 수행하는 단계의 수를 셀 수 있다. 그러나 일반적으로 어떤 알고리즘이 좋은지 나쁜지를 판단하기 위해서는, 가능한 모든 인스턴스에 대해 그것이 어떻게 동작하는지를 알아야 한다.

최선, 최악, 평균 경우 복잡도(Best/Worst/Average-Case Complexity)의 개념을 이해하기 위해서 해당 알고리즘에 입력될 수 있는 가능한 모든 데이터 인스턴스에 대해 알고리즘을 실행한다고 가정하자. 예를 들어 정렬 문제의 경우, 가능한 입력 인스턴스 집합은 모든 가능한 n<ref>n은 자연수이다.</ref>개의 키의 배열이다. 이때 각 입력 인스턴스는 figure 1에 나타난 좌표평면 위의 한 점으로 나타내어 진다. 해당 좌표평면에서 x축은 입력 문제의 인스턴스 크기를, y축은 해당 인스턴스에서 알고리즘이 수행한 단계의 수를 나타낸다. 이때 우리는 해당 좌표평면에서 세 가지 흥미로운 함수를 정의할 수 있다.
# Worst-Case Complexity는 크기 n의 어떤 인스턴스에 대하여 수행된 단계 수의 최댓값으로 정의되는 함수이다. 이는 평면에서 가장 높은 점을 지나는 곡선에 해당된다.
# Best-Case Complexity는 크기 n의 어떤 인스턴스에 대하여 수행된 단계 수의 최솟값으로 정의되는 함수이다. 이는 평면에서 가장 낮은 점을 지나는 곡선에 해당된다.
# Worst-Case Complexity<ref>기대 시간(expected time)이라고도 한다.</ref>는 크기 n의 모든 인스턴스에 대해 실행된 단계 수의 평균으로 정의되는 함수이다.
일반적으로는 이 세가지 측정치 중 Worst-Case Complexity가 가장 유용하다.

==각주==