GN⁺: TinyKVM - Varnish 위에서 실행되는 빠른 샌드박스
(info.varnish-software.com)- KVM 기반의 단일 프로세스 샌드박스
- 일반 리눅스 프로그램이나 특정 API를 사용하는 프로그램을 샌드박스에서 실행 가능
- 하드웨어 가상화를 사용해 네이티브 성능을 제공
- KVM API의 일부분만 사용 → 코드베이스가 작고 효율적임
TinyKVM의 설계
-
정적 Linux ELF 프로그램 실행 지원
- 동적 실행 파일 지원은 추후 추가 예정
- 외부 HTTP 서버 또는 캐시에대한 액세스를 제공하기 위해 API로 확장도 가능
- 현재 AMD64(x86_64)에서 작동하며, AArch64(64비트 ARM) 포팅 계획 중
-
Hugepage 지원
- 게스트 페이지에 hugepage 생성 가능
- 호스트에서도 hugepage 사용 가능 → 성능 개선 효과
- 예: 2MB 페이지 할당 시 LLVM 컴파일 성능 5% 증가 확인
-
빠른 함수 호출
- 게스트에서 함수 호출 시 오버헤드는 2μs
- 타이머 없이 실행 시 오버헤드는 1.2μs로 감소
-
원격 디버깅 지원
- GDB로 원격 디버깅 가능
- 디버깅 후 정상적인 프로그램 재개 가능
-
Copy-on-Write 지원
- 자체 fork 기능 지원 → 메모리 복제 최소화 가능
- 예: 6GB 모델을 복제할 경우 인스턴스당 260MB 메모리만 필요
-
빠른 상태 초기화
- 게스트 상태를 빠르게 리셋 가능 → 보안 강화
- 요청마다 리셋하면 상태 노출 위험 감소
-
간소화된 코드베이스
- KVM API에서 약 42k LOC 사용
- TinyKVM 자체 코드베이스는 약 9k LOC → 경쟁 솔루션보다 훨씬 작음
- 예: Wasmtime 350k LOC, FireCracker 165k LOC
-
정적 페이지 테이블 생성
- 런타임 중 페이지 테이블 수정 불가 → 보안 강화
- 페이지 테이블 무결성 체크 수행
-
분리된 프로세스 컨텍스트
- KVM 게스트는 별도의 PCID/ASID 사용 → 스펙터(Spectre) 등 추측 실행 공격에 강함
-
보안 강화된 커널
- SMEP, SMAP 활성화
- 사용자 모드에서 CPU 예외 처리 가능
시스템 콜 처리
-
호스트와의 API 연결
- SYSCALL/SYSRET 또는 OUT 명령어를 통해 시스템 콜 수행
- 시스템 콜 수행 시 VM exit 발생 → 약 1μs 소요
- 작은 호출을 줄이고 큰 입출력 단위의 API 설계 권장
벤치마크
-
VM 호출 오버헤드
- VM 리셋 시 tail latency 측정
- 리셋 없이 단순 호출 시 오버헤드는 낮음
-
메모리 성능
- 메모리 성능은 정상 수준
- 예: HTTP 벤치마크에서 초당 1500개 AVIF 인코딩 가능
-
JPEG → AVIF 변환 성능
- 초당 약 1582개 이미지 변환 가능
- YUV 변환 경로를 사용해 무손실 변환 가능
빠른 샌드박스 성능의 이유
-
I/O 및 드라이버 미사용
- I/O, 드라이버, 가상 장치 없음 → 성능 저하 방지
- CPU 자원만 사용 → 네이티브 속도에 근접
-
Hugepage 최적화
- hugepage 사용으로 페이지 워크 감소 → 성능 개선
- 대규모 LLM 워크로드에서 99.7% 네이티브 성능 달성
-
빠른 VM 호출
- 게스트에서 함수 호출 시 오버헤드 최소화
- 네이티브 CPU 속도로 데이터 처리 가능
한계점
-
vCPU 수 감소 불가
- KVM API에서 vCPU 수 감소 불가능
- 다중 프로세싱은 여러 VM을 병렬 실행해 해결 가능
-
리셋 성능 저하 문제
- VM 상태 리셋 시 성능 저하 발생 가능
- 하지만 상태 공유 및 복제를 통해 해결 가능
향후 과제
- Intel TDX 및 AMD SEV 지원 추가
- AArch64 포팅
- 메모리 잠금(KVM_MEM_READONLY) 기능 추가 → 보안 강화
- 사용자 친화적인 API 개선
- 동적 링크 로딩 지원 추가 → Varnish와 통합 강화
결론
- TinyKVM은 가장 작고 빠른 샌드박스 솔루션 중 하나임
- 보안 강화와 성능 최적화를 모두 달성
- 코드베이스가 작아 유지 보수 용이
- 오픈 소스 라이브러리로 제공 중 → 관심 있다면 코드 저장소 확인 가능
Hacker News 의견
-
이 내용을 정말 좋아함. 계속해서 지금 하고 있는 일을 멈추지 않았으면 좋겠음
- IncludeOS의 주요 기여자라는 것을 알고 있었음. 이 블로그 글을 읽으면서 가장 먼저 떠오른 프로젝트였음
- 네트워크 기능 가상화에 오랫동안 집착해 왔음. 분산 시스템에서 작업 단위를 분리하는 가장 자연스러운 경계이며, 깔끔한 추상화와 효율적인 확장 메커니즘을 제공함
- Varnish를 프로덕션에서 매우 만족스럽게 사용 중임. nginx보다도 더 신뢰할 수 있는 부분임. 보통은 존재조차 잊어버릴 정도임. 제대로 설정한 이후로는 버그의 원인이 된 적이 없음
-
Firecracker와 비슷하지만 훨씬 빠름
- 가장 마음에 드는 점은 VM의 상태를 미리 정의된 상태로 즉시 재설정할 수 있는 능력임. 실제로 재시작하지 않고 VM을 재시작하는 것과 같음
- 지속적으로 공격을 받는 네트워크 서비스에 이상적인 조치로 보임. 공격이 성공하더라도 다음 요청에서 결과가 지워짐
- ML 모델 실행기와 같이 그 점을 염두에 두지 않고 작성된 프로그램에 대한 쉬운 COW 페이지 공유도 꽤 좋음
-
원본 게시물: 링크
- 이 주제와 관련된 게시물을 많이 찾을 수 있음
-
정말 흥미로움. 2.5us 스냅샷 복원 성능이 Wasmtime과 동등하지만 네이티브 코드를 실행할 수 있는 큰 장점이 있음. 다만, 훨씬 느리지만 여전히 마이크로초 단위의 상호 운용성을 가짐
- tinykvm_examples 저장소에 이미 QuickJS 데모가 있지만, JIT 기능을 갖춘 JavaScript 런타임을 실행할 수 있는지 확인하면 훨씬 빠를 것임
- React 앱을 서버 렌더링하는 실험에서 네이티브 QuickJS는 약 12-20ms, v8은 JIT 워밍업 후 2-4ms였음
- 더 공부해야겠지만, 샌드박스 내에서 실행되고 모든 HTTP 요청을 Varnish를 통해 처리하는 Deno 같은 단일 실행 파일을 만들고 싶음
- 지정된 JS URL을 가져온 후 스냅샷을 찍고 각 요청이 격리된 스냅샷에서 실행되도록 함
- 요청당 랜덤 시드를 재설정하는 메커니즘이 필요할 것임
-
기본적으로 libkrun과 같은 것 아닌가? 링크
-
이게 정확히 의도된 용도는 아니지만, X 서버(또는 Wayland)를 실행한 경험이 있는 사람 있나요?
- Mac에서 RDP 서버에 대해 개발 중이며, 가끔 클라이언트를 위해 다른 필요가 있음. 현재는 UTM(QEMU Mac 프론트엔드)과 DietPi(매우 간소화된 Debian) VM을 사용 중임
- Docker에 익숙하지만, 그래픽 서버를 실행하기 위해 어떤 절차가 필요한지 잘 알고 있음. 더 간단한 방법이 있는지 궁금함
-
흥미롭지만 큰 그림을 이해하는 데 어려움을 겪고 있음. 커널 없이 VM에서 사용자 프로세스를 실행하는 것인가? 모든 시스템 호출이 VM 종료가 되어 호스트로 프록시되는 것인가? 아니면 시스템 호출이 없는 것인가?
-
사용 사례에 맞다면 정말 멋진 것임
- 게시물에서 몇 가지 노트
- TinyKVM이 99.7% 네이티브 속도로 실행됨을 발견함
- 파일이나 네트워크 액세스가 필요하지 않고 정적이라면, 그냥 바로 실행될 수 있음
- TinyKVM 게스트는 수정할 수 없는 작은 커널을 가짐
-
정말 멋짐
- 자체 호스팅 PaaS를 위해 마이크로-VM을 탐색 중이며, 오버헤드가 적은 것이 정말 흥미로운 옵션처럼 보임
-
기사에는 Varnish 위에서 실행된다는 내용이 없으며, 실제로 저자는 그것이 Varnish를 실행하기 위한 것이 아니라고 말함