| Extending Applications Safely and Efficiently | |
|---|---|
| Author | Yusheng Zheng, UC Santa Cruz; Tong Yu, eunomia-bpf Community; Yiwei Yang, UC Santa Cruz; Yanpeng Hu, ShanghaiTech University; Xiaozheng Lai, South China University of Technology; Dan Williams, Virginia Tech; Andi Quinn, UC Santa Cruz |
| Conference | USENIX OSDI 2025 |
| https://www.usenix.org/system/files/osdi25-zheng-yusheng.pdf | |
| Year | 2025 |
개요
논문은 EIM과 bpftime이라는 모델을 개발하였다. 본 논문은 사용자 공간 애플리케이션(userspace application)을 보다 쉽고 효율적으로 확장하기 위한 모델을 제안한다. EIM은 확장(extension)이 수행할 수 있는 동작을 리소스(resource)로 간주하며, 이를 통해 확장 가능한 기능들을 체계적으로 정의하고 관리할 수 있도록 하였다. 이러한 EIM 모델을 기반으로, 논문은 bpftime이라는 프레임워크를 설계하였다. Bpftime은 eBPF를 활용하여 EIM 모델을 효과적으로 반영할 수 있도록 구현되었다. 또한 Bpftime은 eBPF, Intel MPK와 같은 다양한 격리 모델(Isolation models), 그리고 동적 바이너리 리라이팅(Dynamic Binary Rewriting) 등의 기법들을 활용하여 효율적이고 안전한 확장 시스템을 구축하였다.
Motivation & Importance
Extenion은 널리 쓰이고 있는 중요한 기술이다. Extension은 실행되면 특정 Extension entry로 jump해서, 제한된 Resource만을 가지고 program을 실행시킨다. 그러나 Extension이 제대로 작동할려면, Extension이 동시에 Host의 State를 보거나 변경시키면서도, Extension이 제한된 리소스만을 접근할 수 있고 Extension의 잘못된 동작이 Host Application에 영향을 미치지 않도록 하여야 한다. 전자를 논문에서는 Interconnectedness, 후자를 Safety라고 정의하였다. 이 두개의 요소는 서로 Trade-off가 있기 때문에 누군가는 이 Trade-off를 정의해주어야 하는 문제가 있다.
- Safe language runtimes (NaCL): Interconnectedness와 Safety를 재정의할 수 없다.
- LwC, RLBox, Shreds: Fine-grained한 리소스 정의를 할 수 없다.
- Orbit, Wedge: Fine-grained한 Interconnectedness와 Safety를 재정희 할 수 없다. 또한 Host application source를 수정하여아만, 다른 Interconnectedness와 Safety를 정의할 수 있다.
Main Idea
EIM은 Interconnectedness와 Safety에 해당하는 feature들을 모두 Resource로 보았다. 예를 들어서 host function을 실행시키거나, 변수를 읽는 행위 또한 Resource로 보았다. 이러한 Resource를 Capability model을 통해서 제한하였다. EIM의 Developer는 Resource에 허용된 범위를 정의하고 Extension manager를 각 Extension이 정의된 행위만 수행하는지를 Enforcement하였다.
또한 이러한 EIM의 Resource model을 효율적으로 수행시키기 위해서 eBPF를 사용하였다. 또한 eBPF를 사용함으로써 기존의 eBPF Framework를 그대로 사용할 수 있어서, kernel과 Application의 수정이 동시에 필요한 상황에서도 효과적으로 Extension을 작성시킬 수 있었다.
Background
Extension Framework Features
- Fine-grained Safety/Interconnectedness tradeoffs: Extension과 Host 간의 Interconnectedness(즉, 확장이 호스트에 얼마나 깊게 접근할 수 있는가)와 Safety(즉, 호스트를 얼마나 강하게 보호할 것인가)는 본질적인 트레이드오프 관계에 있다. 다양한 사용 사례들이 존재하기 때문에, 이를 하나의 고정된 정책으로 일반화하기는 어렵다. 따라서 상황에 따라 조정 가능한 유연한 설계가 요구된다.
- Isolation: 확장은 절대적으로 Host Application을 손상시키지 않아야 하며, 메모리 접근이나 실행 흐름에 있어서 격리가 보장되어야 한다.
- Efficiency: 격리와 안전성을 제공함에도 불구하고, 시스템은 성능 저하 없이 효율적으로 동작해야 한다. 확장성 및 안전성과 더불어 낮은 오버헤드 또한 핵심 목표 중 하나다.
Limitations of State-of-the-Art
- Native execution 방식은 애플리케이션과 확장을 동일한 실행 컨텍스트에서 실행하며, 확장을 본래 프로그램의 일부로 취급한다. 대표적인 예로는 LD_PRELOAD나 동적 바이너리 계측 기법들이 있다. 이러한 접근법은 효율성은 높지만, isolation을 제공하지 않으며 fine-grained한 safety와 interconnectedness 간의 trade-off 조절이 불가능하다.
- SFI 기반 도구들은 확장을 격리하기 위해 사용되며, NaCl, WebAssembly, Lua, RLBox, XFI 등이 있다. 이 중 일부 도구는 safety/interconnectedness 조절 인터페이스가 없으며, 대신 호스트 애플리케이션이 직접 safety 위반을 확인해야 하는 구조로 설계되었고, 이로 인해 버그가 발생하기도 한다. RLBox나 XFI는 일부 조절이 가능하지만 granularity가 부족하고 특정 확장 동작을 제한하는 기능도 미흡하다. 또한 대부분의 SFI 기반 도구들은 런타임 검증을 수행하기 때문에 효율성이 떨어진다.
- Subprocess isolation 시스템은 확장을 호스트 애플리케이션으로부터 분리된 프로세스로 실행한다. Wedge, Shreds, lwC, Orbit 등이 이에 해당한다. 이러한 시스템은 격리를 제공하지만, lwC와 Shreds는 세밀한 interconnectedness/safety 조절이 어렵고, Orbit과 Wedge는 해당 조절이 가능하더라도 호스트 애플리케이션의 코드 수정을 필요로 하며, 본래 extensibility를 목적으로 설계되지 않았다. 또한 context-switch와 유사한 오버헤드로 인해 자주 실행되는 확장에는 비효율적이다.
- eBPF uprobes는 주로 커널 확장을 위해 설계되었지만, uprobe 인터페이스를 통해 userspace 확장도 가능하다. 이 방식은 호스트 애플리케이션과의 격리는 제공하지만 fine-grained한 safety/interconnectedness 조절이 불가능하다. 또한, 확장 진입 시마다 소프트웨어 브레이크포인트가 걸리고, 커널로 트랩이 발생하여 효율성도 낮다.
- Aspect-oriented programming은 확장을 허용하지만 기존의 aspect-oriented 언어는 safety/interconnectedness 조절을 제공하지 않는다. 예를 들어 AspectJ에서 확장이 악용될 경우, 공격자는 제한 없이 호스트 애플리케이션에 접근할 수 있다.
Design & Implementation
Extension Interface Model (EIM)
EIM Model은 모든 허용가능한 시스템의 작업들을 Resource라는 추상화를 통해서 나타내었다. 이를 통해서 Fine-grained한 Interconnectedness/Safety의 구분이 가능하도록 하였다. EIM Specification은 크게 Development-time과 Deplymetn-time으로 구분된다.
- Development-time EIM Specification
- Development-time specification은 Application의 리소스를 어떻게 제한할 것인지를 정의한다. Development-time specficiation은 다음 세개의 정의로 구성된다.
- State capability: Host application의 global state에 대한 permission을 정의한다. capability는 이름과 함께
read(var)또는write(var)형태로 특정 변수 var에 대한 읽기 또는 쓰기 권한을 지정한다. - Function capability: Function capability는 호스트 애플리케이션에서 제공하는 함수를 호출할 수 있는 권한을 정의한다. 이는 함수 이름, 함수 프로토타입, 그리고 선행 조건(pre-conditions) 및 후행 조건(post-conditions)을 포함하는 제약 조건으로 구성된다. 또한 Constraint를 통해서 인자나 반환값 조건을 지정할 수 있다.
- Extension entry: Extension entry는 확장이 오버라이드할 수 있는 호스트 애플리케이션 내의 함수 진입 지점을 정의한다. 보통 함수 이름, 원래 함수의 이름, 그리고 함수 시그니처로 구성된다. 많은 애플리케이션은 이미 함수 interposition을 통한 확장 지점을 포함하고 있으므로, 이러한 지점을 활용하여 EIM 사양에 포함할 수 있다.
- Deployment-time EIM Specification
- Development-time specification은 Development-time specification에 명시된 Allowable한 Capability중에 어떤것을 특정 함수가 사용할지를 정의할 수 있다. EIM은 instruction과 memory resource를 제공한다. 즉 memory access에 대한 capability와 instruction을 얼마나 실행시킬 수 있을지에 대한 capability를 받는다. 예를 들어서, 두번째 Figure에서의 line 4번은 infinite한 instruction실행이 가능하며, nginxTimx과 readPid그리고 r에 대한 read권한을 요구하고 있다.
Bpftime Design
위의 시스템을 적용시키긴 위해선 효율적인 Isolation mechanisms이 필요하다. 본 논문은 bpftime이라는 새로운 eBPF를 활용한 매커니즘을 제시하였다. 이는 효율성, Compatibility측면에서 다른 SFI와 같은 매커니즘 대비 우월하다. Bpftime에 Annotation을 할 수 있는 기능을 추가하여서, EIM의 Capabiltiy모델을 Annotation으로 구현가능하도록 하였다. 또한 uprobe와 uretprobe를 추가해서, function에 hook을 걸수 있도록 하였다. 이를 통해서 capability model에서 정의된 동작이 제대로 이루어지고 있는지 체크하였다. 또한 sysenter와 sysexit을 통해서 system call이 정의된 것만 실행되고 있는지를 체크하였다. 사용자가 정의한 동작은 YAML을 통해서 eBPF프로그램으로 변환되어 컴파일 되도록 하였다.
Bpftime loader는 bpftime의 validity를 검증하는 간단한 user-level verifer와 rewriter로 구성된다. 이는 user-level에서의 동작 검증 및 live update를 위해서 사용된다. Verifier는 제약 조건을 eBPF verifier가 이해할 수 있는 constraints구문으로 변환하고, 최종적으로 verifier가 이해할 수 있는 형태로 리소스 제약을 삽입하는 역활을 한다.
Bpftime은 Extension의 메모리 접근을 방직하기 위해서 ERIM과 같은 방식을 채택하였다. Intel MPK로 Extension메모리와 Host application의 메모리를 분리하고, Context switching시에 Intel MPK값을 변경시키는 방법으로 Memory를 Isolation하였다. 이를 통해서 효과적인 isolation이 가능하도록 하였다.
Case Study
EIM은 observability, hot patching, security enforcement등 다양한 분야에서 사용될 수 있다.
Conclusion
이 논문의 강점은 분명하다. eBPF 기반 확장 시스템을 위한 추상화 계층인 bpftime과, 명시적 권한 기반 모델인 EIM을 통해, 확장 기능의 Safety와 Interconnectedness 사이의 trade-off를 구조적으로 설계할 수 있도록 한 점은 주목할 만하다. 특히 기존 시스템들이 이와 같은 제어를 암묵적으로 애플리케이션 레벨에서 처리하는 데 반해, 이 모델은 이를 명확한 형태로 드러낸다.
보안하고 싶은 부분은, EIM 모델이 제공하는 Fine-grained 제어는 유연성과 안전성을 동시에 보장할 수 있는 강력한 수단이지만, 실제 확장을 개발하는 개발자 입장에서 보면 capability를 일일이 정의해야 하는 부담이 발생할 수 있다. 이 점에서 기존 애플리케이션이 내부 권한을 상속하거나 캡슐화하는 lightweight한 context 기반 모델과 비교했을 때, 개발 편의성이나 성능 측면에서의 이점이 얼마나 뚜렷한지는 조금 더 명확하게 설명될 수 있었으면 한다.
또한, 논문 전반에서 bpftime과 EIM의 역할이 서로 혼재되어 소개되어 있어, 각 구성 요소의 기여도를 파악하는 데 다소 어려움이 있다. 예를 들어, 빠른 uprobe 실행이나 zpoline 기반 syscall hooking 등 bpftime 고유의 성능 최적화 기법이 EIM과 어떤 연관성을 갖고 있는지에 대한 구체적인 설명이 부족하다. 전체적으로 bpftime의 설계 원리와 메커니즘에 대한 보다 명확한 기술이 추가된다면, 시스템 전반의 이해도를 높이는 데 큰 도움이 될 것이다. 일례로, Evaluation은 전체적으로 bpftime에 대한 raw-performance분석이라서 EIM을 적용하였을 경우에 어떤 부분에서 Overhead가 발생하며, Code수정을 위해서는 어느정도의 노력이 들어갔고, EIM을 사용하였을 경우의 Fault isolation testing이라던지 EIM의 Capability모델에 대한 Evalauation이 추가되었으면 한다.