कॉपी-ऑन-राइट से 1 मिलीसेकंड से कम में VM सैंडबॉक्स

Docker कंटेनर शुरू करने में लगभग 500 मिलीसेकंड लगते हैं। Firecracker microVM को लगभग 125 मिलीसेकंड लगते हैं। V8 isolate को लगभग 5 मिलीसेकंड। लेकिन हल्के सैंडबॉक्स की एक नई पीढ़ी, जो copy-on-write मेमोरी फोर्किंग का इस्तेमाल करती है, किसी अलग-थलग execution environment को 1 मिलीसेकंड से कम में शुरू कर सकती है, अक्सर 50-200 माइक्रोसेकंड की रेंज में। यह इतनी तेज़ है कि हर एक function call के लिए नया सैंडबॉक्स बनाया जा सकता है।

यह सिर्फ़ एक छोटा सुधार नहीं है। यह इस बात में गुणात्मक बदलाव है कि sandboxing क्या कर सकती है। जब सैंडबॉक्स बनाने में 500ms लगते हैं, तो आप उन्हें कम बनाते हैं और दोबारा इस्तेमाल करते हैं। जब इसमें 50μs लगते हैं, तो आप हर untrusted input, हर plugin invocation और हर user request के लिए एक बना सकते हैं। सिक्योरिटी मॉडल 'tenants को isolate करो' से बदलकर 'हर operation को isolate करो' हो जाता है।

Copy-on-Write असल में क्या है

Copy-on-write (CoW) एक operating system तकनीक है, जिसमें आप बिना वास्तव में कोई data copy किए मेमोरी region की 'copy' बना लेते हैं। मूल और copy दोनों एक ही physical memory pages को पॉइंट करते हैं, जो read-only मार्क होते हैं। दोनों एक जैसे दिखते हैं, दोनों में एक ही data होता है। असली copy तभी होती है जब इनमें से कोई एक page पर write करने की कोशिश करता है। उस समय kernel write को रोकता है, सिर्फ़ उस एक page की copy बनाता है, और write को copy पर आगे बढ़ने देता है।

Unix का fork() system call 1990 के दशक से यही तकनीक इस्तेमाल कर रहा है। जब आप एक process को fork करते हैं, तो child को parent की मेमोरी की पूरी copy मिलती है, लेकिन CoW की वजह से असल में कोई data copy नहीं होता। अगर child तुरंत exec() call करता है (जो आम तौर पर होता है), तो वह अपनी मेमोरी पूरी तरह बदल देता है और CoW pages बस छोड़ दिए जाते हैं। यानी fork लगभग मुफ़्त था।

// Classic fork() — copy-on-write in action
pid_t pid = fork();
// At this point:
// - Parent and child share ALL physical memory pages
// - Both have identical virtual address spaces
// - Pages are marked read-only in both
// - Zero data has been copied
if (pid == 0) {
// Child process
// Reading shared_data is free — same physical page
int value = shared_data[0];
// Writing triggers CoW — only THIS page gets copied
shared_data[0] = 42;
// Now child has its own copy of this one page
// Parent's page is unchanged
}

Fork से Sandbox तक

CoW sandbox का मुख्य विचार यह है: नया VM या container शुरू से boot करने के बजाय एक 'template' environment को पहले से boot करके रखें (runtime, libraries और initial state लोड करके), फिर CoW से उसे fork करके तुरंत copies बनाएं। हर copy ठीक उसी state से शुरू होती है जहाँ template ने छोड़ा था, यानी पूरी तरह initialized और execute करने के लिए तैयार, लेकिन अपनी अलग isolated मेमोरी में चलती है।

Performance का फ़र्क बहुत बड़ा है। पारंपरिक VM startup में ये काम होते हैं: kernel load करना, hardware initialize करना, filesystems mount करना, init system शुरू करना, application code लोड करना और runtime initialize करना। Firecracker जैसे aggressive optimization के बाद भी (Firecracker इसे काफ़ी हद तक कम कर देता है), आप अभी भी सैकड़ों मिलीसेकंड का initialization काम कर रहे होते हैं।

CoW forking यह सारा काम छोड़ देता है। Template ने initialization पहले ही कर लिया है। Fork माइक्रोसेकंड में एक पहले से initialized copy बना देता है। 'startup cost' बस नई address space बनाने और page table entries duplicate करने का kernel bookkeeping है, यानी कुछ हज़ार operations, चाहे template कितनी भी मेमोरी इस्तेमाल करे।

जहाँ यह खेल बदल देता है

Serverless Functions

Cold starts serverless computing की सबसे बड़ी परेशानी हैं। AWS Lambda का cold start 100-500ms लेता है, और JVM-based runtimes में और ज़्यादा। latency-sensitive workloads के लिए यह अस्वीकार्य है, इसलिए users को instances को warm रखना पड़ता है (जो serverless के उद्देश्य को ही खत्म कर देता है) या unpredictable latency स्वीकार करनी पड़ती है।

CoW sandboxes के साथ cold starts sub-millisecond तक गिर जाते हैं। हर invocation एक 'cold start' हो सकता है, क्योंकि cold starts लगभग मुफ़्त होते हैं। Warm pools की ज़रूरत नहीं, idle instances से मेमोरी की बर्बादी नहीं, invocations के बीच पुराना state नहीं। हर function execution को initialization की कीमत चुकाए बिना एक साफ़, isolated environment मिलता है।

Plugin और Extension Systems

Untrusted plugins को सुरक्षित रूप से चलाना software की सबसे कठिन समस्याओं में से एक है। Browsers ने JavaScript के लिए V8 isolates से इसे हल किया। लेकिन arbitrary code (compiled extensions, scripting languages, binary plugins) के लिए isolation के विकल्प सीमित रहे हैं: containers (per-request isolation के लिए बहुत धीमे) या WebAssembly (जिसका ecosystem और language support सीमित है)।

CoW sandboxes एक बीच का रास्ता देते हैं: host environment की isolated copy में arbitrary code चलाएं, sub-millisecond setup और teardown के साथ। Plugin को पूरा OS environment (filesystem, network, libraries) दिखता है, लेकिन उसके बदलाव सीमित रहते हैं, यानी sandbox बंद होते ही सारे बदलाव गायब हो जाते हैं। CI systems, notebook environments और build tools में user-submitted code के लिए यह आदर्श है।

Security Isolation

Untrusted input प्रोसेस करते समय, जैसे कोई uploaded PDF parse करना, user-provided HTML render करना या database query execute करना, ऑपरेशन को isolated sandbox में चलाने से किसी भी exploit का नुकसान सीमित हो जाता है। अगर PDF parser में buffer overflow है, तो हमलावर को एक disposable sandbox पर कंट्रोल मिलता है जो बस नष्ट होने वाला है, application server पर नहीं।

हर untrusted operation के लिए process isolation का यह तरीका पारंपरिक sandboxing में अव्यावहारिक रहा है, क्योंकि overhead processing time से ज़्यादा हो जाता था। अगर PDF parse करने में 10ms लगते हैं, तो container बनाने में 500ms खर्च करना कोई मतलब नहीं रखता। लेकिन CoW sandbox बनाने में 100μs खर्च करना लगभग मुफ़्त है।

Implementation की बारीकियाँ

एक व्यावहारिक CoW sandbox system बनाने के लिए सिर्फ़ fork() call करने से आगे कई समस्याएँ सुलझानी पड़ती हैं।

• मेमोरी हिसाब। CoW से मेमोरी उपयोग अस्पष्ट हो जाता है। अगर template 1 GB इस्तेमाल करता है और आप 100 copies fork करते हैं जिनमें से हर एक 10 MB बदलती है, तो physical memory उपयोग लगभग 2 GB है (1 GB shared + 100 × 10 MB unique), 100 GB नहीं। Kernel shared और private pages का हिसाब रखता है, लेकिन हर sandbox का सटीक उपयोग जानने के लिए /proc/[pid]/smaps parse करना पड़ता है।
• Filesystem isolation। CoW मेमोरी संभालता है, लेकिन filesystem writes को अलग से isolate करना होता है। Overlay filesystems (overlayfs) files के लिए CoW semantics देते हैं: sandbox template का filesystem देखता है, लेकिन writes एक अलग layer में जाते हैं। Sandbox बंद होने पर overlay हटा दिया जाता है।
• Network isolation। हर sandbox को interference रोकने के लिए अपना network namespace चाहिए। Linux namespaces यह देते हैं, लेकिन network namespaces बनाने में measurable overhead होता है। कुछ systems पहले से बने namespaces का pool दोबारा इस्तेमाल करते हैं।
• Resource limits। जो sandbox असीमित मेमोरी allocate करता है या बेहिसाब CPU खपाता है, वह denial-of-service का रास्ता है। cgroups memory, CPU और I/O की limits देते हैं, लेकिन cgroup बनाने/हटाने में overhead जुड़ता है। यहाँ भी pooling मदद करती है।
• Deterministic cleanup। Sandbox बंद होने पर उसके सारे resources (मेमोरी, file descriptors, network connections, IPC objects) भरोसेमंद तरीके से साफ़ होने चाहिए। PID namespaces मदद करते हैं: namespace के init process को मार दें, तो उसके सारे descendants भी मर जाते हैं।

CoW बनाम WebAssembly Sandboxes

WebAssembly (Wasm) दूसरी प्रमुख हल्की sandboxing तकनीक है। दोनों की तुलना करना उपयोगी है, क्योंकि ये बुनियादी तौर पर अलग-अलग trade-offs चुनते हैं।

Wasm sandboxes linear memory model वाली memory-safe virtual machine में code चलाते हैं। Sandbox अपनी linear memory के बाहर कुछ भी एक्सेस नहीं कर सकता: कोई filesystem नहीं, कोई network नहीं, कोई system calls नहीं (जब तक WASI के ज़रिए स्पष्ट रूप से न दिए जाएँ)। यह बेहद सुरक्षित है, लेकिन सीमित भी है: मौजूदा code को Wasm में recompile करना पड़ता है, और सभी languages Wasm में ठीक से compile नहीं होतीं।

CoW sandboxes native code को एक isolated OS environment में चलाते हैं। Sandbox के पास पूरा OS interface होता है (हो सकता है seccomp filters से सीमित हो), वह कोई भी binary चला सकता है और सामान्य system libraries इस्तेमाल करता है। यह कम प्रतिबंधात्मक है, लेकिन कम सुरक्षित भी है, क्योंकि isolation boundary OS process model है, जिसकी attack surface Wasm के न्यूनतम VM से बड़ी है।

Wasm चुनें जब: आप sandbox किए जा रहे code को नियंत्रित करते हैं, आपका workload Wasm में साफ़ compile होता है, और आपको संभव सबसे मज़बूत isolation चाहिए। CoW sandboxes चुनें जब: आपको मौजूदा arbitrary binaries चलाने हैं, आपके workload को OS-level क्षमताएँ चाहिए (filesystem, network, child processes), और आप न्यूनतम attack surface से ज़्यादा compatibility को प्राथमिकता देते हैं।

असली पेच: Multithreaded Programs में Fork

fork() की एक प्रसिद्ध समस्या है: यह सिर्फ़ call करने वाले thread को copy करता है। अगर parent के 20 threads हैं, तो child को एक मिलता है। बाकी 19 threads द्वारा पकड़े गए mutexes child की मेमोरी में अब भी held मार्क रहते हैं, लेकिन उन्हें पकड़ने वाले threads मौजूद नहीं होते। पहली बार जब child इनमें से किसी mutex को acquire करने की कोशिश करेगा, तो वह deadlock हो जाएगा।

CoW sandbox systems इसका हल यह सुनिश्चित करके निकालते हैं कि fork के समय template process single-threaded हो। आम तौर पर इसका मतलब है: template में सब कुछ initialize करें (libraries लोड करें, runtime सेट करें, initial state तैयार करें), फिर main thread को छोड़कर सारे threads रोकें, fork करें, और हर child को ज़रूरत पड़ने पर threads दोबारा बनाने दें। Initialization की कीमत एक बार चुकाई जाती है; fork threading के खतरे से बचाता है।

कुछ नए तरीके userfaultfd या custom page fault handlers से CoW जैसा व्यवहार बनाते हैं, बिना fork() पर निर्भर हुए। ये multithreading की समस्या से बचते हैं, लेकिन complexity बढ़ाते हैं और kernel-level coordination ज़्यादा माँगते हैं।

किस पर नज़र रखें

Sub-millisecond sandboxing अभी शुरुआती दौर में है, लेकिन इसके building blocks मज़बूत हैं (fork, namespaces, cgroups, overlayfs सभी परिपक्व हैं)। इनके ऊपर बनने वाले systems, यानी serverless computing, CI/CD और सुरक्षित code execution के लिए, साबित कर रहे हैं कि per-operation isolation बड़े पैमाने पर व्यावहारिक है। जैसे-जैसे ये tools परिपक्व होंगे, यह धारणा कि sandboxing महंगी है, उतनी ही पुरानी लगेगी जितनी यह धारणा कि real-time applications के लिए garbage collection बहुत धीमी है। Overhead गायब हो रहा है, और 'सब कुछ sandbox करो' के सुरक्षा फ़ायदों को अनदेखा करना मुश्किल होता जा रहा है।