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

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

كان حلنا هو تخزين السياسة المطبقة لكل inode في الذاكرة المؤقتة باستخدام مفتاح من ثلاث حقول: معرف مساحة أسماء التركيب، ومعرف التركيب، ورقم inode. يخزن قيمة التخزين المؤقت access_index وحالة التخزين المؤقت. هذا النهج في التخزين المؤقت خفض تكلفة وحدة المعالجة المركزية للنواة بنسبة تقارب 90%. نستخدم خريطة تجزئة LRU بحد أقصى 10000 إدخال للبحث الفعال.

يمنع التخزين المؤقت المشي المتكرر في المسار للوصول المتكرر إلى الملفات، وهو ما يفيد بشكل خاص أحمال عمل قواعد البيانات مثل Postgres التي تعيد الوصول إلى مسارات الملفات نفسها بشكل متكرر. تطبيقنا مفتوح المصدر متاح على https://github.com/bomfather/agent.

الكيانات الرئيسية: أشخاص: bomfather