TinyKVM - Varnish पर चलने वाला तेज़ sandbox

 (info.varnish-software.com)
6 पॉइंट द्वारा GN⁺ 2025-03-15 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • KVM-आधारित single-process sandbox
    • सामान्य Linux प्रोग्राम या किसी खास API का उपयोग करने वाले प्रोग्राम sandbox में चलाए जा सकते हैं
  • hardware virtualization का उपयोग करके native performance प्रदान करता है
  • KVM API का केवल एक हिस्सा उपयोग करता है → codebase छोटा और efficient है

TinyKVM की डिज़ाइन

  • static Linux ELF प्रोग्राम चलाने का समर्थन
    • dynamic executable support बाद में जोड़ा जाएगा
    • बाहरी HTTP server या cache तक access देने के लिए API के रूप में इसे बढ़ाया भी जा सकता है
    • अभी AMD64(x86_64) पर काम करता है, और AArch64(64-bit ARM) पर port करने की योजना है
  • Hugepage support
    • guest page के लिए hugepage बनाया जा सकता है
    • host पर भी hugepage इस्तेमाल किया जा सकता है → performance बेहतर होती है
    • उदाहरण: 2MB page allocation पर LLVM compile performance में 5% वृद्धि देखी गई
  • तेज़ function call
    • guest से function call करने पर overhead 2μs है
    • timer के बिना चलाने पर overhead घटकर 1.2μs रह जाता है
  • remote debugging support
    • GDB से remote debugging की जा सकती है
    • debugging के बाद प्रोग्राम को सामान्य रूप से फिर शुरू किया जा सकता है
  • Copy-on-Write support
    • अपना fork फीचर सपोर्ट करता है → memory duplication को न्यूनतम किया जा सकता है
    • उदाहरण: 6GB मॉडल को clone करने पर प्रति instance केवल 260MB memory चाहिए
  • तेज़ state initialization
    • guest state को तेज़ी से reset किया जा सकता है → security मजबूत होती है
    • हर request पर reset करने से state exposure का जोखिम कम होता है
  • सरल codebase
    • KVM API से लगभग 42k LOC उपयोग होते हैं
    • TinyKVM का अपना codebase लगभग 9k LOC है → competing solutions की तुलना में बहुत छोटा
    • उदाहरण: Wasmtime 350k LOC, FireCracker 165k LOC
  • static page table generation
    • runtime के दौरान page table बदले नहीं जा सकते → security मजबूत होती है
    • page table integrity check भी किया जाता है
  • अलग process context
    • KVM guest अलग PCID/ASID का उपयोग करता है → Spectre जैसी speculative execution attacks के खिलाफ अधिक मजबूत
  • security-hardened kernel
    • SMEP, SMAP enabled हैं
    • user mode में CPU exception handling संभव है

system call handling

  • host के साथ API connection
    • SYSCALL/SYSRET या OUT instruction के ज़रिए system call किया जाता है
    • system call के समय VM exit होता है → लगभग 1μs लगता है
    • छोटे calls कम करने और बड़े I/O unit वाले API design की सिफारिश की जाती है

benchmark

  • VM call overhead
    • VM reset के समय tail latency मापी गई
    • reset के बिना simple call करने पर overhead कम होता है
  • memory performance
    • memory performance सामान्य स्तर की है
    • उदाहरण: HTTP benchmark में प्रति सेकंड 1500 AVIF encodings संभव हैं
  • JPEG → AVIF conversion performance
    • प्रति सेकंड लगभग 1582 images convert की जा सकती हैं
    • YUV conversion path का उपयोग करके lossless conversion संभव है

तेज़ sandbox performance के कारण

  • I/O और driver का उपयोग नहीं
    • I/O, driver और virtual device नहीं हैं → performance degradation से बचाव
    • केवल CPU resources का उपयोग → native speed के करीब
  • Hugepage optimization
    • hugepage के उपयोग से page walk कम होता है → performance बेहतर होती है
    • बड़े LLM workload में 99.7% native performance हासिल की गई
  • तेज़ VM call
    • guest से function call करते समय overhead न्यूनतम
    • native CPU speed पर data processing संभव

सीमाएँ

  • vCPU की संख्या घटाई नहीं जा सकती
    • KVM API में vCPU की संख्या कम करना संभव नहीं
    • multi-processing को कई VM समानांतर चलाकर संभाला जा सकता है
  • reset performance degradation की समस्या
    • VM state reset करते समय performance में गिरावट आ सकती है
    • लेकिन state sharing और cloning से इसे संभाला जा सकता है

आगे के काम

  • Intel TDX और AMD SEV support जोड़ना
  • AArch64 porting
  • memory locking (KVM_MEM_READONLY) फीचर जोड़ना → security मजबूत करना
  • user-friendly API में सुधार
  • dynamic link loading support जोड़ना → Varnish integration को और बेहतर करना

निष्कर्ष

  • TinyKVM सबसे छोटे और सबसे तेज़ sandbox solutions में से एक है
  • यह security hardening और performance optimization दोनों हासिल करता है
  • codebase छोटा होने से maintenance आसान है
  • यह open source library के रूप में उपलब्ध है → रुचि हो तो code repository देखी जा सकती है

TinyKVM repository

संबंधित पढ़ाई

2 टिप्पणियां

 
xcutz 2025-03-16

काफ़ी अनोखा है
 
GN⁺ 2025-03-15
Hacker News राय

  • यह वाकई बहुत पसंद आया। उम्मीद है कि आप जो अभी कर रहे हैं, उसे जारी रखेंगे और रुकेंगे नहीं

    • मुझे पता था कि आप IncludeOS के प्रमुख contributors में से एक हैं। यह ब्लॉग पोस्ट पढ़ते समय सबसे पहले वही project याद आया
    • मैं लंबे समय से network function virtualization को लेकर जुनूनी रहा हूँ। distributed systems में work units को अलग करने के लिए यह सबसे स्वाभाविक boundary है, और यह साफ abstraction तथा efficient scaling mechanism देता है
    • मैं production में Varnish को बहुत संतोषजनक तरीके से इस्तेमाल कर रहा हूँ। कुछ मामलों में यह nginx से भी अधिक भरोसेमंद है। आम तौर पर तो इसका अस्तित्व भी भूल जाता हूँ। एक बार सही तरह से configure कर देने के बाद यह कभी bugs का कारण नहीं बना

  • Firecracker जैसा है, लेकिन काफी तेज

    • इसमें सबसे पसंदीदा बात यह है कि VM की state को पहले से परिभाषित state पर तुरंत reset किया जा सकता है। यह practically VM को restart किए बिना restart करने जैसा है
    • यह लगातार attack झेल रही network services के लिए आदर्श उपाय लगता है। भले ही attack सफल हो जाए, अगली request में उसका परिणाम मिट जाता है
    • ML model runners जैसे, इस बात को ध्यान में रखकर न लिखे गए programs के लिए आसान COW page sharing भी काफी अच्छा है

  • मूल पोस्ट: लिंक

    • इस विषय से जुड़े बहुत सारे पोस्ट मिल सकते हैं

  • वाकई दिलचस्प है। 2.5us snapshot restore performance Wasmtime के बराबर है, लेकिन native code चला पाने का बड़ा फायदा है। हालांकि, यह काफी धीमा है, फिर भी interoperability microsecond स्तर की बनी रहती है

    • tinykvm_examples repository में पहले से QuickJS demo है, लेकिन अगर यह देखा जाए कि JIT feature वाला JavaScript runtime चल सकता है या नहीं, तो यह और भी तेज हो सकता है
    • React app को server-render करने वाले एक प्रयोग में native QuickJS लगभग 12-20ms था, जबकि v8 JIT warm-up के बाद 2-4ms था
    • मुझे और पढ़ना होगा, लेकिन मैं Deno जैसी single executable file बनाना चाहता हूँ जो sandbox के अंदर चले और सभी HTTP requests को Varnish के ज़रिए संभाले
    • निर्धारित JS URL को fetch करने के बाद snapshot लिया जाए, और फिर हर request isolated snapshot में execute हो
    • संभवतः per-request random seed reset करने का mechanism चाहिए होगा

  • क्या यह मूल रूप से libkrun जैसा ही नहीं है? लिंक

  • शायद इसका ठीक-ठीक यही intended use case नहीं है, लेकिन क्या किसी ने इसमें X server (या Wayland) चलाने का अनुभव लिया है?

    • मैं Mac पर RDP server के लिए development कर रहा हूँ, और कभी-कभी clients के लिए दूसरी ज़रूरतें भी होती हैं। अभी मैं UTM (QEMU Mac frontend) और DietPi (बहुत सरल बनाया गया Debian) VM इस्तेमाल कर रहा हूँ
    • मैं Docker से परिचित हूँ, लेकिन graphics server चलाने के लिए कौन-सी प्रक्रिया चाहिए, यह अच्छी तरह जानता हूँ। सोच रहा हूँ कि क्या इससे आसान कोई तरीका है

  • दिलचस्प है, लेकिन बड़ी तस्वीर समझने में दिक्कत हो रही है। क्या यह kernel के बिना VM में user process चलाता है? क्या सभी system calls VM exit बन जाते हैं और host पर proxy किए जाते हैं? या फिर system calls होते ही नहीं?

  • अगर use case के हिसाब से फिट बैठे, तो यह वाकई शानदार है

    • पोस्ट से कुछ notes
    • पता चला कि TinyKVM 99.7% native speed पर चलता है
    • अगर file या network access की ज़रूरत नहीं है और यह static है, तो इसे बस सीधे चलाया जा सकता है
    • TinyKVM guest में एक छोटा kernel होता है जिसे बदला नहीं जा सकता

  • वाकई शानदार

    • self-hosted PaaS के लिए मैं micro-VMs को explore कर रहा हूँ, और कम overhead वाला यह विकल्प काफी दिलचस्प लग रहा है

  • लेख में यह नहीं कहा गया है कि यह Varnish के ऊपर चलता है, और वास्तव में लेखक कहता है कि यह Varnish चलाने के लिए नहीं है