مهندسو Google التي تساهم في Linux kernel أعلنوا أنهم اكتشفوا المئات من "ظروف العرق" ، في النواة باستخدام KCSAN. تعمل الشركة منذ فترة طويلة على AddressSanitizer للعثور على الأخطاء المتعلقة بفساد الذاكرة أو UndefinedBehaviorSanitizer للسلوك غير المحدد في التعليمات البرمجية.
هذا الوقت، تقدم Google أداة جديدة للكشف عن "ظروف السباق" لنواة Linux تسمى KCSAN (Kernel Concurrency Sanitizer). نقاط الضعف الحرجة هذه ليست جديدة. في الواقع، فإن تحدث ظروف السباق عندما يصل اثنان أو أكثر من الخيوط في نفس العملية إلى نفس موقع الذاكرة في وقت واحد، حيث يكون أحد الوصول على الأقل للكتابة ، وعندما لا تستخدم الخيوط أي أقفال حصرية للتحكم في وصولهم إلى هذه الذاكرة.
عند استيفاء هذه الشروط ، لا يكون أمر الوصول حتميًا وقد يعطي الحساب نتائج مختلفة من تشغيل إلى آخر بناءً على هذا الترتيب.
يُنظر إلى شروط السباق بشكل متزايد على أنها أخطاء وصول متزامنة ويصعب تكرارها والتشخيص في برامج موازية. Linux kernel هو نظام برمجي واسع النطاق ، حيث يخضع التوازي كثيف الخيط وتشذير الخيط غير الحتمي لظروف تنافسية.
يمكن أن تكون بعض المواقف التنافسية حميدة ، لكن العديد منها الذي تم تحديده حتى الآن يعتبر أخطاء.
توفر نواة Linux عدة آليات لتجنب وإدارة هذه الأنواع من الشروط نظرًا لوجود أدوات مثل Thread Analyzer أو KTSAN (Kernel Thread Sanitizer) لاكتشاف أخطاء التنفيذ الحرجة في Linux Kernel.
ومع ذلك ، فإن Google ، التي تساهم أيضًا في Linux kernel ، اقترحت مؤخرًا KCSAN، كاشف جديد لظروف السباق للنواة ، مشابه لـ KTSAN.
وفقًا لـ Google ، يركز KCSAN على اكتشاف المواقف التنافسية في كود kernel. كاشف الضربات الحرجة الديناميكي هذا هو بديل لمطهر خيط Kernel (KTSAN)
وفقًا لتفسير Google ، يعتمد KCSAN على نقاط مراقبة أخذ العينات ، على عكس كاشف KTSAN ، وهو كاشف سباق حرج قبل الحدث. الأولويات الرئيسية في تصميم KCSAN هي الافتقار إلى الإيجابيات الخاطئة وقابلية التوسع والبساطة.
يستخدم KCSAN أدوات الترجمة للوصول إلى الذاكرة. KCSAN متوافق مع مجمعي GCC و Clang. مع GCC ، يتطلب الإصدار 7.3.0 أو أحدث ومع Clang ، يتطلب الإصدار 7.0.0 أو أحدث.
في صفحة المشروع على GitHubكتب Marco Elver من Google أنه باستخدام KCSAN في الاختبارات الشهر الماضي ، وجدوا في يومين فقط أكثر من 300 موقف منافسة أساسي فريد. يوفر KCSAN العديد من خيارات التكوين لتخصيص سلوكه.
"لقد استخدمنا KCSAN من خلال Syzkaller لعدة أسابيع ، ووجدنا العديد من الأخطاء. في البداية في سبتمبر 2019 ، حددنا أكثر من 300 موقف منافسة فريد على مدار يومين فقط ".
قالت Google إن النهج العام يعتمد على DataCollider ، كاشف ديناميكي آخر للمواقف التنافسية في وحدات النواة. ولكن على عكس DataCollider ، لا تستخدم KCSAN نقاط مراقبة الأجهزة ، وبدلاً من ذلك تعتمد على أدوات الترجمة.
يتم تنفيذ نقاط المراقبة باستخدام تشفير فعال يخزن النوع والحجم وعنوان الوصول في ملف طويل. تتمثل مزايا استخدام نقاط المراقبة المرنة في قابلية النقل ومرونة أكبر في تقييد الوصول الذي يمكن أن تنشطه نقطة المراقبة.
فيما يلي بعض النقاط الرئيسية التي قدمتها KCSAN لـ Google:
- أداء عالي: وقت تشغيل KCSAN ضئيل ولا يتطلب تأمين حالة مشتركة لكل وصول. والنتيجة هي أداء أفضل بكثير من KTSAN.
- لا توجد ذاكرة إضافية: وفقًا لجوجل ، لا يلزم وجود ذاكرة تخزين مؤقت. يستخدم التنفيذ الحالي عددًا صغيرًا من الأطوال لتشفير معلومات نقطة المراقبة ، وهو أمر لا يكاد يذكر.
- أمر الذاكرة: لا يعرف KCSAN قواعد التحكم في نموذج ذاكرة kernel Linux (LKMM). يمكن أن يؤدي هذا إلى فقدان السباقات الحرجة (السلبيات الخاطئة) مقارنةً بكاشف السباق قبل الحدث مثل KTSAN
- دقة: وفقًا لـ Google ، فإن KCSAN غير دقيق لأنه يستخدم استراتيجية أخذ العينات ؛
- يتطلب التعليق التوضيحي: الحد الأدنى من التعليقات التوضيحية مطلوب خارج وقت تشغيل KCSAN. في حالة مستمع حدث شرط مسبق ، فإن أي حذف يؤدي إلى نتائج إيجابية خاطئة ، وهو أمر مهم بشكل خاص في سياق النواة التي تتضمن آليات توقيت مخصصة.
- الكشف عن عمليات الكتابة الديناميكية من الأجهزة: من خلال فحص قيم البيانات أثناء إعداد نقطة المراقبة ، يمكن أيضًا اكتشاف عمليات الكتابة الديناميكية من الأجهزة.