يستخدم المهندسون eBPF لفحص سلوك نواة لينكس دون وحدات النواة

قال دان فينيران، المدافع الرئيسي عن المجتمع في Isovalent لدى Cisco، لـ InfoQ إن المطورين يستخدمون الآن eBPF بما يتجاوز بكثير تصفية الحزم، إذ تطبّق الفرق هذه التقنية على قابلية الملاحظة في Linux، وشبكات Kubernetes، وفرض تعليمات syscall، والتجارب المبكرة على Windows.

أنشأ مطورو النواة eBPF انطلاقًا من نموذج Berkeley Packet Filter الأقدم. كان BPF الأصلي يوفّر للمسؤولين طريقة لتصفية الحزم. احتفظ eBPF بفكرة البرامج الصغيرة المرفقة بخطافات النواة، ثم وسّع النموذج إلى طبقة امتداد أوسع.

قال فينيران إن جاذبية التقنية تبدأ بمسار المساهمة في Linux. فالفريق الذي يريد سلوكًا جديدًا في النواة يمكنه كتابة patch، وطلب المراجعات من القائمين على صيانة الأنظمة الفرعية، والانتظار حتى يُدرج التغيير في النواة، ثم الانتظار مرة أخرى حتى تقوم توزيعات مثل Ubuntu أو Red Hat بشحن تلك النواة. هذا المسار يحمي مستخدمي Linux، لكنه يبطئ الفرق التي تحتاج الآن إلى رؤية إنتاجية أو إلى فرضٍ مباشر.

يمكن للفرق أيضًا كتابة kernel modules، لكن هذا المسار يجلب ارتباطًا قويًا بالإصدارات ومخاطر الأعطال. وغالبًا ما يَبنِي مؤلف الوحدة البرمجية ضد إصدار محدد من النواة. ويمكن لشفرة الوحدة السيئة أن تمنع التنفيذ أو تتسبب في تعطل المضيف. يمنح eBPF المطورين هدفًا أصغر مع حواجز أمان أقوى.

أما الحاجز الذي شدد عليه فينيران فهو verifier. يقوم المطورون بترجمة شفرة eBPF إلى bytecode، ثم يطلبون من النواة تحميلها. يتحقق verifier من الوصول إلى الذاكرة، وحدود الحلقات، وسلوك البرنامج قبل أن تقبل النواة البرنامج. وإذا وجد verifier وصولًا غير آمن أو مسار تنفيذ يمكن أن يعمل بلا حدود، فإنه يرفض البرنامج.

يمنح هذا النموذج مهندسي المنصات مسار نشر فوريًا لسلوك على مستوى النواة. يمكنك إرفاق الشفرة بخطافات مدعومة على نظام يعمل بالفعل وإزالتها دون إعادة بناء النواة. ما زلت تحتاج إلى مهارة منخفضة المستوى، وغالبًا بلغة C، والآن أكثر فأكثر باستخدام أدوات Rust، لكنك تتجنب ملف المخاطر التشغيلية الخاص بوحدة نواة كاملة.

كما عارض فينيران فكرة أن على المطورين تعلم eBPF قبل أن يتمكنوا من استخدام الأدوات المبنية عليه. فمشروع Cilium، وهو مشروع شبكات Kubernetes من Isovalent، يخفي كثيرًا من هذه الآلية خلف تجريدات السياسات والخدمات. يحدد المشغلون أي الأعباء العملية يمكنها التواصل مع غيرها. ويستخدم مهندسو Cilium eBPF تحت الغطاء لتوجيه الحزم وفرض السياسة.

وينطبق النمط نفسه على Tetragon، الذي بناه مهندسو Isovalent للأمن وقت التشغيل وقابلية الملاحظة. ويمكن لفرق الأمن استخدام سياسات Tetragon من دون كتابة برامج eBPF خام. يَعلق Tetragon على syscalls وغيرها من خطافات النواة، ويسجل النشاط، ويمكنه حظر إجراءات محددة قبل أن تكملها النواة.

يغيّر هذا النموذج قبل الخطاف عمليات الأمن. فقد يسجل وكيل تقليدي حذف ملف أو تصعيد امتيازات بعد أن تكمل النواة الإجراء. مع eBPF، يمكن لفريق الأمن وضع منطق قبل syscall وإيقاف العملية. وقدّم فينيران أمثلة مثل حظر الحذف في دليل مشروع محمي، أو تقييد الوصول إلى ملفات قاعدة البيانات على daemon قاعدة البيانات، أو منع تصعيد الامتيازات خارج المسارات المعتمدة.

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

ربط فينيران الآلية نفسها بقابلية الملاحظة. يمكن للمطورين إرفاق برامج بـ kernel probes، وreturn probes، وtracepoints، وsyscalls، وuser-space probes. وهذا يمنح الفرق رؤية في الوصول إلى الملفات، ونداءات الشبكة، ونداءات المكتبات، ومسارات التخزين، وسلوك المشغلات من دون إضافة مكتبات instrumentation إلى كل تطبيق.

وقدمت الاستفادة من وحدات معالجة الرسوميات مثالًا واحدًا. وصف فينيران فرقًا تربط برامج eBPF بالقرب من مسارات NVIDIA CUDA driver لقراءة النشاط منخفض المستوى وربطه بطلبات أعباء العمل. ويمكن لفرق المنصات استخدام هذه الإشارة للحفاظ على انشغال المسرّعات المكلفة وتقليل السعة المهدرة.

ومع ذلك، لا يزال على المطورين فهم الحدود. فـ verifier يقيّد حجم البرنامج، وسلوك الحلقات، والوصول إلى الذاكرة. وقد تكون رسائل الخطأ صعبة على المستخدمين الجدد، خصوصًا عندما يعيد verifier تشخيصات كثيفة. قال فينيران إن المجتمع حسّن الأدوات والوثائق، بما في ذلك كتاب Liz Rice، Learning eBPF، وموارد مجتمع eBPF.

وقد فتحت Microsoft أيضًا مسارًا لـ eBPF على Windows عبر مشروع eBPF for Windows. يحصل مستخدمو Linux على دعم eBPF داخل النواة، بينما لا يزال مستخدمو Windows بحاجة إلى برامج تشغيل إضافية. وقال فينيران إن هذا الاتجاه متعدد المنصات قد يساعد المؤسسات على توحيد قابلية الملاحظة والسياسة عبر أنظمة تشغيل مختلطة.

كما تناول الحديث micro VMs وعزل Kubernetes. قال فينيران إن الفرق يمكنها دمج العزل على مستوى النواة مع ضوابط وقت التشغيل المعتمدة على eBPF. وتقلل micro VMs من مخاطر kernel المشتركة، بينما لا يزال بإمكان Tetragon فحص السلوك وفرضه داخل البيئات الضيفة المدعومة. وأضاف أن Edera أضافت دعم eBPF داخل نواة micro VM الخاصة بها.

كما طُرحت عمليات التشغيل المدفوعة بالذكاء الاصطناعي كمسار مستقبلي. قال فينيران إن Cisco والمجتمع جرّبا سياسات Tetragon المولّدة بالنماذج، رغم أن النماذج الحالية يمكن أن تنتج حقول سياسة تبدو معقولة لكنها تفشل في التحقق. ووصف سير عمل مرجحًا يحدد فيه أداة ثغرات شكل الاستغلال، ثم يصوغ نموذج سياسة، ثم يختبر إنسان أو نظام تحقق آلي السياسة قبل النشر.

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

بالنسبة لمعظم المطورين، سيبقى eBPF تفصيلًا تنفيذيًا داخل أدوات مثل Cilium وTetragon. أما لفرق المنصات والأمن وقابلية الملاحظة، فيقدّم طريقة مباشرة لفحص سلوك النظام وتشكيله عند حدود النواة من دون شحن kernel modules أو انتظار تغييرات النواة upstream.