صناديق عزل فائقة السرعة بتقنية Copy-on-Write

يستغرق تشغيل حاوية Docker نحو 500 ملّي ثانية، ويحتاج Firecracker microVM نحو 125 ملّي ثانية، أما V8 isolate فيحتاج نحو 5 ملّي ثوانٍ. لكن جيلاً جديداً من الصناديق الخفيفة، يعتمد على تقنية نسخ الذاكرة عند الكتابة (Copy-on-Write)، يمكنه تشغيل بيئة تنفيذ معزولة في أقل من ملّي ثانية، وغالباً في نطاق 50 إلى 200 ميكروثانية. وهذه سرعة تكفي لإنشاء صندوق جديد لكل استدعاء دالة على حدة.

هذا ليس تحسيناً تدريجياً فقط، بل تغيير نوعي في ما يمكن للعزل أن يفعله. عندما يكلّف إنشاء الصندوق 500 ملّي ثانية، تنشئه بحذر وتعيد استخدامه. أما عندما تصبح التكلفة 50 ميكروثانية، فيمكنك إنشاء صندوق لكل مدخل غير موثوق، ولكل إضافة تُستدعى، ولكل طلب مستخدم. وبذلك ينتقل نموذج الأمان من «عزل المستأجرين» إلى «عزل كل عملية على حدة».

ماذا يعني Copy-on-Write فعلاً

نسخ الذاكرة عند الكتابة (CoW) تقنية في أنظمة التشغيل تُنشأ فيها «نسخة» من منطقة ذاكرة دون نسخ أي بيانات فعلياً. يشير الأصل والنسخة إلى صفحات الذاكرة الفيزيائية نفسها، وتُعلَّم كلها للقراءة فقط. لا يمكن التمييز بينهما، فكلاهما يرى البيانات ذاتها. ولا تحدث النسخة الفعلية إلا عندما يحاول أحدهما الكتابة إلى صفحة. عندها يعترض النواة عملية الكتابة، وتنسخ تلك الصفحة وحدها، ثم تُنفَّذ الكتابة على النسخة.

استخدم استدعاء النظام fork() في يونكس هذه التقنية منذ التسعينيات. عند تنفيذ fork لعملية، تحصل العملية الابنة على نسخة كاملة من ذاكرة الأب، لكن بفضل CoW لا تُنسخ أي بيانات فعلياً. وإذا استدعت الابنة فوراً exec() (وهو الأمر المعتاد)، فإنها تستبدل ذاكرتها بالكامل، وتُحرَّر صفحات CoW ببساطة. لقد كان عملية 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 إلى صندوق معزول

فكرة الصناديق المعتمدة على CoW هي: بدلاً من تشغيل آلة افتراضية أو حاوية جديدة من الصفر، يُشغَّل مسبقاً قالب (template) يحوي وقت التشغيل والمكتبات والحالة الأولية، ثم يُعمل له fork بتقنية CoW لإنشاء نسخ فورية. تبدأ كل نسخة من الحالة نفسها التي توقف عندها القالب، أي مهيأة بالكامل وجاهزة للتنفيذ، لكنها تعمل في فضاء ذاكرة معزول خاص بها.

الفرق في الأداء هائل. يتضمن إقلاع الآلة الافتراضية التقليدية: تحميل النواة، وتهيئة العتاد، وتركيب أنظمة الملفات، وتشغيل نظام التهيئة (init)، وتحميل كود التطبيق، وتهيئة وقت التشغيل. وحتى مع التحسين المكثف (إذ يبسّط Firecracker هذه العملية بشكل كبير)، لا تزال تحتاج إلى مئات الملّي ثانية من أعمال التهيئة.

يتجاوز fork بتقنية CoW كل ذلك، فالقالب أنجز التهيئة مسبقاً، والنسخة تُنشأ في ميكروثوانٍ. أما «كلفة التشغيل» فهي مجرد أعمال نواة لإنشاء فضاء عناوين جديد ونسخ مدخلات جداول الصفحات، أي بضعة آلاف من العمليات مهما بلغ حجم الذاكرة التي يستخدمها القالب.

أين تغيّر هذه التقنية قواعد اللعبة

الدوال بلا خادم

تُعد البدايات الباردة (Cold starts) الكابوس الأكبر في الحوسبة بلا خادم. تستغرق AWS Lambda ما بين 100 و500 ملّي ثانية في البدء البارد، وأكثر من ذلك في بيئات JVM. وهذا غير مقبول للأحمال الحساسة للزمن، ما يدفع المستخدمين إما إلى إبقاء النسخ دافئة (وهذا يُفسد الغرض من الحوسبة بلا خادم)، أو إلى قبول زمن استجابة غير متوقع.

مع صناديق CoW تنخفض البدايات الباردة إلى أقل من ملّي ثانية. يمكن لكل استدعاء أن يكون «بدءاً بارداً»، لأن البدء البارد صار عملياً بلا كلفة. لا حاجة إلى مجمعات مُسخّنة، ولا هدر للذاكرة في نسخ خاملة، ولا حالة قديمة متبقية بين الاستدعاءات. تحصل كل عملية تنفيذ على بيئة نظيفة ومعزولة دون دفع كلفة التهيئة.

أنظمة الإضافات والملحقات

تشغيل الإضافات غير الموثوقة بأمان من أصعب المشكلات في البرمجيات. حلّتها المتصفحات لجافاسكربت عبر V8 isolates. لكن مع الكود العشوائي، كالملحقات المترجمة ولغات السكربت والإضافات الثنائية، ظلت خيارات العزل محصورة بين الحاويات (وهي بطيئة جداً للعزل لكل طلب) وWebAssembly (ومنظومته ولغاته محدودة).

تقدم صناديق CoW مساراً وسطاً: تشغيل كود عشوائي في نسخة معزولة من بيئة المضيف، مع إعداد وتفكيك في أقل من ملّي ثانية. ترى الإضافة بيئة نظام تشغيل كاملة (ملفات وشبكة ومكتبات)، لكن تعديلاتها محصورة، فعند خروج الصندوق تختفي كل التغييرات. وهذا مثالي للكود الذي يرفعه المستخدمون في أنظمة CI، وبيئات الدفاتر البرمجية، وأدوات البناء.

العزل الأمني

عند معالجة مدخلات غير موثوقة، كتحليل ملف PDF مرفوع، أو عرض HTML قدّمه المستخدم، أو تنفيذ استعلام قاعدة بيانات، فإن تشغيل العملية داخل صندوق معزول يحد من نطاق الضرر لأي ثغرة استغلال. فإذا كان محلل PDF يعاني من تجاوز سعة مخزن مؤقت (buffer overflow)، فسيحصل المهاجم على تحكم في صندوق مؤقت على وشك التدمير، لا في خادم التطبيق نفسه.

ظل هذا النهج، أي عزل العمليات لكل عملية غير موثوقة، غير عملي مع الصناديق التقليدية لأن كلفته كانت تفوق زمن المعالجة. فإذا كان تحليل ملف PDF يستغرق 10 ملّي ثوانٍ، فإن إنفاق 500 ملّي ثانية على إنشاء حاوية لا معنى له. أما إنفاق 100 ميكروثانية على إنشاء صندوق CoW فهو رخيص إلى حد بعيد.

تفاصيل التنفيذ

بناء نظام عملي لصناديق CoW يتطلب حل عدة مشكلات تتجاوز مجرد استدعاء fork().

• محاسبة الذاكرة. يجعل CoW استخدام الذاكرة ملتبساً. فإذا استخدم القالب 1 GB ثم أنشأت 100 نسخة تعدّل كل منها 10 MB، فإن استهلاك الذاكرة الفيزيائية يبلغ نحو 2 GB (1 GB مشتركة + 100 × 10 MB خاصة)، لا 100 GB. تتتبع النواة الصفحات المشتركة والخاصة، لكن الحصول على استهلاك دقيق لكل صندوق يتطلب تحليل /proc/[pid]/smaps.
• عزل نظام الملفات. يتولى CoW الذاكرة، لكن كتابات الملفات تحتاج إلى عزل منفصل. توفر أنظمة الملفات المتراكبة (overlayfs) دلالات CoW للملفات: يرى الصندوق نظام ملفات القالب، لكن الكتابات تذهب إلى طبقة منفصلة. وعند خروج الصندوق تُتلف هذه الطبقة.
• عزل الشبكة. يحتاج كل صندوق إلى فضاء أسماء شبكة (network namespace) خاص به لمنع التداخل. توفر نوى لينكس هذه الميزة، لكن إنشاء فضاءات الأسماء له كلفة قابلة للقياس. لذلك تعيد بعض الأنظمة استخدام مجموعة من فضاءات الأسماء المُنشأة مسبقاً.
• حدود الموارد. الصندوق الذي يخصص ذاكرة بلا حد أو يستهلك معالجاً دون قيود يمثل ناقلاً لهجمات الحرمان من الخدمة. توفر cgroups حدوداً للموارد (الذاكرة والمعالج وI/O)، لكن إنشاء cgroups وتدميرها يضيفان كلفة. ومرة أخرى يساعد التجميع (pooling).
• التنظيف الحتمي. عند خروج الصندوق يجب تنظيف كل موارده بموثوقية: الذاكرة، ووصفات الملفات، واتصالات الشبكة، وكائنات IPC. تساعد فضاءات أسماء PID هنا، إذ يكفي قتل عملية init في فضاء الأسماء حتى تُقتل كل العمليات المتفرعة عنها.

صناديق CoW مقابل صناديق WebAssembly

WebAssembly (Wasm) هي التقنية الرئيسية الأخرى للعزل الخفيف. ويستحق الأمر مقارنتهما لأنهما يقومان على مفاضلات مختلفة جوهرياً.

تشغّل صناديق Wasm الكود داخل آلة افتراضية آمنة للذاكرة بنموذج ذاكرة خطية (linear memory). لا يستطيع الصندوق الوصول إلى أي شيء خارج ذاكرته الخطية: لا ملفات، ولا شبكة، ولا استدعاءات نظام (إلا ما يُتاح صراحة عبر WASI). وهذا آمن للغاية لكنه مقيّد: يجب إعادة ترجمة الكود القائم إلى Wasm، وليست كل اللغات تُترجم إليه بكفاءة.

تشغّل صناديق CoW كوداً أصلياً داخل بيئة نظام تشغيل معزولة. يملك الصندوق واجهة نظام تشغيل كاملة (قد تُقيّدها مرشحات seccomp)، ويستطيع تشغيل أي ملف ثنائي، ويستخدم مكتبات النظام المعتادة. وهذا أقل تقييداً لكنه أقل أماناً، فحدود العزل هنا هي نموذج عمليات نظام التشغيل، وله سطح هجوم أكبر من آلة Wasm الافتراضية الصغيرة.

اختر Wasm عندما: تتحكم في الكود المعزول، وينترجم حملك بشكل نظيف إلى Wasm، وتحتاج أقوى عزل ممكن. واختر صناديق CoW عندما: تحتاج إلى تشغيل ملفات ثنائية موجودة، ويتطلب حملك إمكانات على مستوى نظام التشغيل (ملفات وشبكة وعمليات فرعية)، وتفضّل التوافق على تقليل سطح الهجوم إلى الحد الأدنى.

المحذور: Fork في البرامج متعددة الخيوط

هناك مزلق معروف مع fork(): فهو ينسخ الخيط المستدعي فقط. فإذا كان للأب 20 خيطاً، تحصل الابنة على واحد فقط. وأي أقفال (mutexes) كانت تمسكها الخيوط التسعة عشر ما زالت مُعلَّمة كمُمسكة في ذاكرة الابنة، لكن الخيوط الممسكة بها لم تعد موجودة. وستدخل الابنة في حالة جمود (deadlock) عند أول محاولة للحصول على أحد تلك الأقفال.

تتجنب أنظمة صناديق CoW هذه المشكلة بضمان أن عملية القالب تكون أحادية الخيط لحظة الـfork. وهذا يعني عادةً: تهيئة كل شيء في القالب (تحميل المكتبات، وإعداد وقت التشغيل، وتجهيز الحالة الأولية)، ثم إيقاف كل الخيوط ما عدا الرئيسي، وعمل fork، والسماح لكل ابنة بإعادة إنشاء الخيوط عند الحاجة. تُدفع كلفة التهيئة مرة واحدة، ويتجنب fork خطر الخيوط.

تستخدم بعض الأساليب الأحدث userfaultfd أو معالجات أخطاء صفحات مخصصة لتطبيق دلالات شبيهة بـCoW دون الاعتماد على fork() إطلاقاً. وهي تتجنب مشكلة تعدد الخيوط، لكنها تضيف تعقيداً وتحتاج إلى تنسيق أعمق على مستوى النواة.

ما الذي يجب مراقبته

العزل بزمن أقل من ملّي ثانية ما زال في بداياته، لكن اللبنات الأساسية متينة (fork وفضاءات الأسماء وcgroups وoverlayfs ناضجة كلها). وتثبت الأنظمة المبنية فوقها، في الحوسبة بلا خادم وCI/CD وتنفيذ الكود الآمن، أن العزل لكل عملية عملي على نطاق واسع. ومع نضج هذه الأدوات، سيصبح الافتراض بأن العزل مكلف قديماً كالافتراض بأن جمع القمامة بطيء أكثر من اللازم للتطبيقات الفورية. وتتلاشى الكلفة، ويصبح من الصعب تجاهل فوائد أمان «العزل لكل شيء».