| Ichnaea: A Framework for Precise Tracking of Memory Objects | |
|---|---|
| Author | Samad Haque, Sibin Mohan, Aaron Paulos, Partha Pal |
| Conference | 20th USENIX Symposium on Operating Systems Design and Implementation (OSDI '26) |
| Year | 2026 |
개요
이 논문은 C/C++ 프로그램에서 관심 있는 memory object의 read/write를 정확하고 낮은 비용으로 추적하기 위해 Memory Protection Keys(MPK)를 사용하는 framework Ichnaea를 제안한다.
Motivation
복잡한 C/C++ 프로그램에서는 pointer와 간접 control flow 때문에 특정 object를 누가 언제 변경했는지 찾기 어렵다. Static analysis는 접근 지점을 놓칠 수 있고, Intel Pin 같은 dynamic instrumentation은 거의 모든 load/store를 검사해 매우 느리다. 기존 mprotect 기반 방식은 page permission이 모든 thread에 적용되므로 multi-thread 환경에서 access를 놓칠 수도 있다. 따라서 모든 memory access를 검사하지 않고, 개발자가 선택한 object가 실제로 접근될 때만 동작하는 tracer가 필요하다.
Importance
Ichnaea는 object tracing의 비용을 전체 instruction 수가 아니라 관심 object의 실제 access 수에 비례하게 만든다. 또한 기존 page-protection tracing에서 trace loss를 만드는 global permission, syscall window, atomic access와 False sharing 문제를 정리하고, MPK의 thread-local permission으로 이를 줄이는 방법을 보여 준다.
Main Idea
ObjOfInterest가 있는 page의 접근을 평소에는 막아 두고, 접근 시 발생한 SIGSEGV를 tracing event로 사용한다. Handler는 현재 thread에서만 page를 잠시 열고 faulting instruction을 실행·기록한 뒤 다시 접근을 막는다. 다른 thread의 permission은 계속 잠겨 있으므로 concurrent access도 각각 포착할 수 있다.
이 과정에서 thread ID, instruction pointer, call stack, timestamp, access type과 write 전후 값을 함께 기록한다.
Design
- Object 등록: 개발자가 API와 간단한 annotation으로 추적할 global/heap object를 지정하면, runtime library가 backing page에 MPK를 설정한다.
- Fault 기반 tracing: Object 접근에서 발생한 fault를 handler가 받아 현재 thread의 permission만 열고, instruction을 emulation한 후 access context를 기록한다.
- Coverage 확장: Shared library의 접근은 같은 fault 경로로 잡는다. Heap object는 별도 page에 배치하며, libc syscall wrapper를 이용해 일부 kernel write도 추적한다. 실행이 끝나면 결과를 JSON으로 저장한다.
Result
SPEC CPU2017에서 Ichnaea는 대부분 native의 1–3배 runtime으로 동작했고, Intel Pin tracer보다 12–60배, mprotect tracer보다 1.3–7배
Contribution
- 기존 object tracer가 multi-thread 환경에서 access를 놓치는 원인을 정리하였다.
- MPK와 instruction emulation을 결합한 selective object-tracing framework를 설계하였다.
- SPEC CPU2017, PostgreSQL과 fuzzing 실험으로 기존 instrumentation 방식보다 낮은 비용을 보였다.
Criticisms
- “Complete tracing”은 userspace 중심의 주장이다. 일부 syscall과 kernel write는 지원하지만 kernel read 전체를 추적하지 못하며 stack object도 지원하지 않는다.
- 모든 object가 아니라 미리 고른 소수의 object에 적합하다. Hot object는 access마다 약 9 µs의 fault 비용을 내고, heap object를 page별로 분리하면 10,000개 실험에서 memory 사용량이 19배 증가했다.
- Emulation하지 못하는 instruction의 slow path는 shared code에 breakpoint를 삽입하므로 multi-thread execution을 방해할 가능성이 있다. 평가도 하나의 Intel MPK 시스템과 synthetic fuzzing workload에 집중되어 있다.
Conclusion
Ichnaea의 핵심은 소수의 중요한 object만 선택하여, 실제 접근이 발생할 때 MPK fault로 추적한다는 것이다. 이 방식은 특정 Object를 추적하기 위해서, Intel Pin보다 크게 낮은 비용으로 풍부한 access context를 제공하지만, kernel·stack·all-object tracing을 대체하는 범용 도구는 아니다.
Major Concenrs
- 제시한 방법에서 Evaluation을 할때, 특정 소수의 Selective한 오브젝트를 대상으로 하였다. 만약 Object가 Allocation보다 Instruction에 더 Senstive한 Object라면 본 논문에서 제시한 결과보다 결과가 안 좋게 보일 수도 있다.
- Still성능이 매우 좋지 못하다. Runtime patch만으로 object pointer관계를 추적하는 더 좋은 방법은 없을지 궁금하다.
- 또한 결국에는 Object annotation을 static time에 해주어야 한단는 점에서, Compiler 단계를 거쳐야 한다. 그렇다면 Compile time에 annotation을 삽입하는 방식과 어떤 차이가 있을지 궁금하다. 이미 Security field에서는 모든 오브젝트의 Control flow를 추적하지만 overhead는 본 논문과 비슷한(!) Compiler-time code injection방식이 소개되어 있다.
- Locality가 중요한 Object, e.g., stack, 으로 확장하기 어렵다. 한 Object에 대한 Fault를 위해서 나머지 Object에도 Fault를 일으킬 가능성이 있기 떄문이다.