ASPLOS 2019
개요
한줄 요약: Pravirtualization의 overhead를 엔지니어링으로 최소화 하여 최대한 빨리 로딩 시간이나 memory footprint를 최소화 하였다. 그 결과는 기존의 full virtualization기반의 lightVM과 같은 기술과 비교하였을때 더 빠르면서 docker와 같은 container기법보다 더 isolating할 수 있는 X-Container를 개발하였다.
Docker는 Cotainer란 개념을 통해서 많은 혁신을 가져왔다. 그러나 Docker와 같은 Container-based 모델은 태생적으로, 만약 한 Container가 Crash나면 다른 Container도 영향을 간접적으로 받는 문제, Kernel module설치를 각각 하지 못하는 문제등 Isolation과 Customization에서 한계를 보인다. 이러한 한계를 극복하기 위해서, Hardware-assisted virtualization support를 통해서, 각각의 container들이 HVM위에서 돌아가도록 하는 방법들이 개발되었다. (즉, HV->contianer처럼 nested된 가상머신을 통해서 virtualization함). nested vm 시스템은 많은 infra에서 금지되어 있거나, 되더라도 큰 overload가 발생한다. gVisor와 같은 user-space kernel또한 전체 systemcall을 사용하지 못하고, 또한 performance overhead가 큰 특징이 있다. 이러한 트렌드에 맞추어서, Lib-OS와 같은 Unikernel모델이 발전하였다. Lib-OS는 특수한 kernel library를 Application에 할당하여 VM위에서 돌리는 것인데, 이러한 Library를 Application에 할당하는 과정이 매우 어렵다는 단점이 있다.
이러한 LibOS의 단점을 극복하기 위해서 Docker, Xen 그리고 LibOS를 적절하게 이용하여 만든 것이 X-Container이다. 이 X conatiner는 다음과 같은 새로운 Security/VM Paradigm과 추가적인 문제들을 해결하기에 적합하다.
- Single-Concerned Containers: 점점 하나의 프로그램의 역활을 세분화 하여, Distributed system에 적합하게 이용할 수 있게 하려는 노력이 아루어지고 있다. 이를 Single-concerned containers라고 한다.
- Isolation Boundary: Isolation은 Kernel Isolation, Process Isolation으로 나루 수 있다. Kernel Isolation은 커널에만 존재하여야 하는 데이터를 저장하기 위해서 가뜩이나 복잡한 커널 코드 베이스에 많은 수정과, Overhead를 가하게 된다. 또한 Process Isolation은 Isolation뿐만 아니라 Shared MMAP처럼 Shared 된 오브젝트도 관리해야 하는데, 이러한 부분을 노리는 매우 다양한 공격들이 개발되고 있다. 이러한 한계를 극복하기 위해서 X-Container은 Process간에는 shared할수 있게 하고, Intel-contianer간에는 X-KERNEL이라는 LibOS를 이용하여, 한정된 수의 Trusted된 code를 이용하여 Isolation이 이루어 질 수 있도록 하였다. (LibOS의 장점...)
- Threat Model and Design: X-KERNEL과 같은 LibOS는 TCB(Trusted Code Base)가 상용 리눅스와 같은 커널에 비교하면 매우 작다는 특징이 있다. 따라서 보안 수준에 있어서 유지 보수하기가 매우 편리하다. X-Container에서는 Intra-container간의 isolation은 다른 프로그램과 비교하였을때 매우 기능이 적다. 따라서 이러한 Process간의 Protection이 이루어져야 하는 프로그램 (ex OpenSSH)와 같은 경우 적용하기 힘든 단점이 있다.
- Unikernel and multiprocessing: Unikernel은 Multiprocessing이 이루어 지지 않는데 (일반적으로 Unikernel == One process와 매칭), 이러면 Apache와 같이 여러 프로세스를 동시에 활용하는 환경에서 문제가 생긴다.
- Binary Compatibility: LibOS는 Binary compatibility에 대한 능력이 없다. 따라서 여러 콘테이너를 포팅하는 과정에서 이 Binary Compatiblitiy를 위해서 매우 귀찮은 작업들이 선행되어야 한다.
- Linux vs XEN: 리눅스와 비교하여 XEN은 훨씬 작으며, Kernel mode와 user mode의 clean seperation을 제공하고, PV device drivers을 통해서 쉽게 디바이스 드라이버와 guest가 통신 할 수 있게 하며, Multi-processing과 관련된 API가 이미 구현되어 있으며, 이미 완성된 ecosystem이 제공된다는 점에서 이를 LibOS로 개조하는 것이 그냥 Linux를 LibOS로 개조하는 것 보다 빠르고 편리하다.
이러한 과정에서 다음과 같은 문제가 발생하였다.
- Memory Management: 기존 LibOS에 비교하여서 Page table에 대한 operation이 있다. 또한 Docker처럼 Dynamic memory allocation을 지원하지 않는다.
- Spwaning speed: 기존의 Container와 비교하여 X-Container은 xen의 VM생성에서 기원한 latency가 포함되어 있기 떄문에 기존의 docker와 같은 container based isolation과 비교하여 추가적인 latency가 존재한다.
구현
- Kernel Isolation의 제거
- System call modification
- Devicemapper based docker utilization