Privbox: Faster System Calls Through Sandboxed Privileged Execution

ATC 2022 Dmitry Kuznetsov, Adam Morrison

개요

시스템콜 Intenstive한 코드를 PrivBox라는 커널과는 분리된, 그러나 커널 Context인 환경에서 실행하여서, Context change overhead를 줄인 논문이다.

Motivation

시스템 콜은 많이 쓰이고 있지만 Context change overhead가 심하다.

Importance

기존 시스템콜 overhead를 줄이기 위한 Work들은 User application을 수정하여야 하였으며, 전통적인 방식들은 기존 Synchronous한 시스템콜 모델을 사용하지 못하였으며, 정확한 동시성을 위한 많은 제약사항들이 존재하였다. 예를 들어 BPF for storage와 같은 경우에는, eBPF의 제약사항으로 인하여 많은 기능들을 사용하지 못하였다.

Main Idea

NaCL의 프로텍션 모델을 빌려와서, Semi-privileged라는 Privbox모델을 디자인 하고, 이 모드에서 Sanboxed된 User application코드를 Kernel address space에서 Kernel privileged로 함께 돌림으로써, System call context change overhead를 줄였다.

Design

PrivBox

Page table에 User application과 kernel의 주소를 동시에 매핑시켜서, 접근할 수 있도록 하였다. 이떄 User memory는 Executable bit를 꺼서 매핑하여서 취약점을 줄였다. 또한 PrivBox는 같은 kernel address space에 매핑되어 있어, system call execution이 function call처럼 이루어 질 수 있도록 하였다.

Memory safety, control flow safety and privileged instructions

Compile time instrumentation과 Virtual memory기법을 동시에 사용하여서 위의 취약점에 대비하였다. NX-bit을 사용하여서 Execution을 막았고, SFI를 컴파일 타임에 삽입하여서 Kernel address에 접근하지 못하도록 하였다. Indirect control-flow instruction또한 SFI를 통해서 막아서 invalid execution을 막았다. 또한 Compiler를 통하여서 Privileged instruction이 포함되어 있지 않도록 보장하였다.

SPAP

SPAP란 새로운 하드웨어 Feature를 디자인 하였다. SPAP는 Semi-privileged access prvention의 약자로서, PTE에 Kernel memory로 mapping된 부분에 Indirect jump와 access permission을 막아주는 기능이다. 이를 하드웨어에 구현하는 것이 SMAP처럼 almost zero overhead를 가지고 구현할 수 있다고 주장하고 있다.

Result

1. system call microbenchdㅔ서 최대 2.2배 빠른 결과가 나왔다.
2. system call intensive한 리얼 월드 워크로드에서 (Redis) 최대 11% 빠른 결과가 나왔다.

Criticize

1. Motivation에서 다른 시스템의 단점으로 Transparent하지 않다는 것을 꼽았지만, PrivBox도 제대로 사용하기 위해서는, 1. 시스템 오버헤드 분석 2. 분석된 코드 섹션을 PrivBox로 분리하는 작업이 필요하다.
2. 말한바와 같이 User space memory를 execute하기 위해서, SMAP/SMEP이 꺼진 상태로 돌아간다. 이는 SMEP으로 막던 기존의 취약점들을 다시금 불러오는 역 효과가 있다. 특히 이 해결방안으로 논문에서 SMEP의 hardware cost를 줄이면 된다고 하는데, 이는 그저 Ad-hoc적인 설명 같다.
3. Side channel attack이 생기면 Kernel address leak매우 심할 것 같다.
4. Libc를 반드시 syscall아 아닌 PrivBox에서 요구하는 API를 사용하도록 바꾸어 주어야 한다.
5. 만약 PrivBox내부에서, 포인터 값을 읽어서 (예- 스택 포인터) 유저에게 준다면? Kernel address leak이 발생한다.
6. SPAP라는 기능을 제시하고 이를 SMAP overhead를 통해서 제시하고 있는데, 사실 SPAP라는 기능은 SFI의 기능을 hardware로 구현한 Ad-hoc적인 Hardware feature이다. 과연 이것이 진짜로 almost no overhead이며 모든 security attack에서 안전함을 보장하는가? 그냥 overhead가 너무 커서 시스템 콜 배칭의 효과가 안 나타나니깐, Ad-hoc적으로 구상한 기능이 아닌가?
7. 하드웨어 적으로 생각보다 쉽게 SFI를 구현할 수 있다는 점은 흥미로운 지점인 것 같다.
8. System call batching이 아직도 전반적인 시스템 성능 향상에 큰 영향을 줄 수 있다는 것이 인상 깊었다.
9. 전반적인 Writing이 구조적으로 잘 짜여있어서 읽기 편한 논문 이었다.