TinyKVM - sandbox cepat yang berjalan di atas Varnish

• Sandbox proses tunggal berbasis KVM
  • Program Linux umum atau program yang menggunakan API tertentu dapat dijalankan di dalam sandbox
• Menyediakan performa native dengan menggunakan virtualisasi perangkat keras
• Hanya menggunakan sebagian dari KVM API → codebase kecil dan efisien

Desain TinyKVM

• Mendukung eksekusi program Linux ELF statis
  • Dukungan untuk executable dinamis direncanakan akan ditambahkan nanti
  • Dapat juga diperluas dengan API untuk menyediakan akses ke server HTTP eksternal atau cache
  • Saat ini berjalan di AMD64(x86_64), dengan rencana porting ke AArch64 (ARM 64-bit)
• Dukungan hugepage
  • Dapat membuat hugepage pada halaman guest
  • Hugepage juga dapat digunakan di host → meningkatkan performa
  • Contoh: saat mengalokasikan halaman 2MB, performa kompilasi LLVM tercatat meningkat 5%
• Pemanggilan fungsi cepat
  • Overhead saat memanggil fungsi dari guest adalah 2μs
  • Saat dijalankan tanpa timer, overhead turun menjadi 1.2μs
• Dukungan debugging jarak jauh
  • Mendukung debugging jarak jauh dengan GDB
  • Setelah debugging, program dapat dilanjutkan kembali secara normal
• Dukungan Copy-on-Write
  • Mendukung fitur fork sendiri → meminimalkan penyalinan memori
  • Contoh: saat menggandakan model 6GB, hanya membutuhkan 260MB memori per instance
• Inisialisasi status cepat
  • Dapat mereset status guest dengan cepat → memperkuat keamanan
  • Jika di-reset pada setiap request, risiko kebocoran status berkurang
• Codebase yang disederhanakan
  • Menggunakan sekitar 42k LOC dari KVM API
  • Codebase TinyKVM sendiri sekitar 9k LOC → jauh lebih kecil dibanding solusi pesaing
  • Contoh: Wasmtime 350k LOC, FireCracker 165k LOC
• Pembuatan page table statis
  • Page table tidak dapat diubah saat runtime → memperkuat keamanan
  • Melakukan pemeriksaan integritas page table
• Konteks proses terisolasi
  • Guest KVM menggunakan PCID/ASID terpisah → lebih tahan terhadap serangan eksekusi spekulatif seperti Spectre
• Kernel yang diperkuat keamanannya
  • SMEP, SMAP diaktifkan
  • Dapat menangani exception CPU di mode pengguna

Penanganan system call

• Koneksi API dengan host
  • System call dilakukan melalui instruksi SYSCALL/SYSRET atau OUT
  • Saat system call dijalankan, terjadi VM exit → memakan waktu sekitar 1μs
  • Disarankan merancang API dengan unit I/O yang besar dan mengurangi pemanggilan kecil

Benchmark

• Overhead pemanggilan VM
  • Tail latency diukur saat VM di-reset
  • Saat hanya melakukan pemanggilan sederhana tanpa reset, overhead rendah
• Performa memori
  • Performa memori berada pada tingkat normal
  • Contoh: pada benchmark HTTP, dapat melakukan 1500 encoding AVIF per detik
• Performa konversi JPEG → AVIF
  • Dapat mengonversi sekitar 1582 gambar per detik
  • Konversi lossless dimungkinkan dengan menggunakan jalur konversi YUV

Alasan performa sandbox yang cepat

• Tidak menggunakan I/O dan driver
  • Tidak ada I/O, driver, atau perangkat virtual → mencegah penurunan performa
  • Hanya menggunakan sumber daya CPU → mendekati kecepatan native
• Optimasi hugepage
  • Penggunaan hugepage mengurangi page walk → meningkatkan performa
  • Pada workload LLM skala besar, mencapai 99.7% performa native
• Pemanggilan VM cepat
  • Overhead saat memanggil fungsi dari guest diminimalkan
  • Dapat memproses data pada kecepatan CPU native

Keterbatasan

• Jumlah vCPU tidak dapat dikurangi
  • Pada KVM API, jumlah vCPU tidak bisa dikurangi
  • Multiprocessing dapat diatasi dengan menjalankan beberapa VM secara paralel
• Masalah penurunan performa saat reset
  • Penurunan performa dapat terjadi saat mereset status VM
  • Namun, ini dapat diatasi melalui berbagi status dan replikasi

Pekerjaan selanjutnya

• Menambahkan dukungan Intel TDX dan AMD SEV
• Porting ke AArch64
• Menambahkan fitur penguncian memori (KVM_MEM_READONLY) → memperkuat keamanan
• Meningkatkan API agar lebih ramah pengguna
• Menambahkan dukungan pemuatan dynamic linking → memperkuat integrasi dengan Varnish

Kesimpulan

• TinyKVM adalah salah satu solusi sandbox yang paling kecil dan cepat
• Mencapai sekaligus penguatan keamanan dan optimasi performa
• Codebase yang kecil membuatnya mudah dipelihara
• Tersedia sebagai library open source → jika tertarik, Anda dapat melihat repositori kodenya

Repositori TinyKVM

[xcutz]

Unik juga

[GN⁺]

Komentar Hacker News

• Sangat menyukai ini. Semoga mereka terus melanjutkan apa yang sedang mereka kerjakan sekarang

  • Sudah tahu bahwa dia adalah kontributor utama IncludeOS. Itu proyek pertama yang terlintas di pikiran saat membaca tulisan blog ini
  • Sudah lama terobsesi dengan virtualisasi fungsi jaringan. Itu adalah batas paling alami untuk memisahkan unit kerja dalam sistem terdistribusi, serta memberikan abstraksi yang rapi dan mekanisme penskalaan yang efisien
  • Sedang menggunakan Varnish di produksi dengan sangat puas. Bahkan lebih bisa diandalkan daripada nginx. Biasanya sampai lupa kalau itu ada. Setelah dikonfigurasi dengan benar, tidak pernah menjadi penyebab bug

• Mirip Firecracker, tetapi jauh lebih cepat

  • Hal yang paling disukai adalah kemampuan untuk langsung mereset status VM ke keadaan yang telah ditentukan sebelumnya. Rasanya seperti me-restart VM tanpa benar-benar me-restart-nya
  • Terlihat seperti langkah ideal untuk layanan jaringan yang terus-menerus diserang. Bahkan jika serangan berhasil, hasilnya terhapus pada permintaan berikutnya
  • Berbagi halaman COW yang mudah untuk program yang ditulis tanpa mempertimbangkan hal itu, seperti eksekutor model ML, juga cukup bagus

• Postingan asli: tautan

  • Bisa menemukan banyak postingan yang terkait dengan topik ini

• Sangat menarik. Kinerja pemulihan snapshot 2.5us setara dengan Wasmtime, tetapi punya keunggulan besar karena bisa menjalankan kode native. Namun, interoperabilitasnya jauh lebih lambat meski tetap berada pada satuan mikrodetik

  • Sudah ada demo QuickJS di repositori tinykvm_examples, tetapi akan jauh lebih cepat jika bisa dipastikan apakah runtime JavaScript dengan kemampuan JIT dapat dijalankan
  • Dalam eksperimen merender aplikasi React di server, QuickJS native sekitar 12-20ms, sedangkan v8 2-4ms setelah pemanasan JIT
  • Perlu dipelajari lebih lanjut, tetapi ingin membuat satu executable seperti Deno yang berjalan di dalam sandbox dan menangani semua permintaan HTTP melalui Varnish
  • Mengambil URL JS yang ditentukan, lalu mengambil snapshot, dan membuat setiap permintaan dijalankan dalam snapshot yang terisolasi
  • Akan diperlukan mekanisme untuk mereset random seed per permintaan

• Bukankah ini pada dasarnya seperti libkrun? tautan

• Ini memang bukan penggunaan yang persis dituju, tetapi adakah yang punya pengalaman menjalankan server X (atau Wayland)?

  • Sedang mengembangkan untuk server RDP di Mac, dan kadang ada kebutuhan lain untuk klien. Saat ini memakai VM UTM (frontend QEMU untuk Mac) dan DietPi (Debian yang sangat dipangkas)
  • Sudah terbiasa dengan Docker, tetapi juga paham prosedur yang diperlukan untuk menjalankan server grafis. Penasaran apakah ada cara yang lebih sederhana

• Menarik, tetapi kesulitan memahami gambaran besarnya. Apakah ini menjalankan proses pengguna di VM tanpa kernel? Apakah semua system call menyebabkan VM keluar lalu diproksikan ke host? Atau memang tidak ada system call?

• Jika cocok dengan use case-nya, ini benar-benar keren

  • Beberapa catatan dari postingan
  • Menemukan bahwa TinyKVM berjalan pada 99.7% kecepatan native
  • Jika tidak memerlukan akses file atau jaringan dan bersifat statis, itu bisa langsung dijalankan
  • Guest TinyKVM memiliki kernel kecil yang tidak dapat dimodifikasi

• Benar-benar keren

  • Sedang mengeksplorasi micro-VM untuk PaaS self-hosted, dan opsi dengan overhead rendah seperti ini terlihat sangat menarik

• Artikelnya tidak mengatakan bahwa ini berjalan di atas Varnish, dan sebenarnya penulis mengatakan bahwa ini bukan untuk menjalankan Varnish