كشفت Google مؤخرًا عن منشور مدونة لديها اتخذ قرار التعطيل افتراضيًا على ChromeOS و Android والخوادم من المنتج، الواجهة غير المتزامنة io_uring، هذا بسبب الوضع الأمني المؤسف في io_uring.
وعليه خلال تحليل نتائج "برنامج مكافآت الضعف" من kCTF ، الذي كان موجودًا منذ عام 2020 ، فقد تبين أن 60٪ من التطبيقات المستلمة بموجب البرنامج تستغل الثغرات الناشئة ولا يتغير الوضع بمرور الوقت ، وهو أمر مقلق للغاية لأنه أصبح نقطة ضعف.
في المجموع ، تم دفع حوالي 1 مليون دولار من المكافآت. عن طريق المآثر ذات الصلة بـ io_uring، في حين أن المبلغ الإجمالي للمكافآت المدفوعة مقابل الثغرات الأمنية في نواة لينكس أثناء وجود المبادرة كان 1,8 مليون دولار مقابل 42 برمجيات إكسبلويت لم يتم إصلاحها بعد (الحد الأقصى للأجر - 133 ألف دولار).
نظرًا لأن Linux kernel هو مكون رئيسي ليس فقط لـ Google ، ولكن أيضًا للإنترنت ، فقد بدأنا في الاستثمار بكثافة في هذا المجال. قمنا بتوسيع مدى وصول VRP والحد الأقصى للمكافأة في عام 2021 (إلى 50 دولار أمريكي) ، ثم مرة أخرى في فبراير 000 (إلى 2022 دولار أمريكي) ، وأخيراً في أغسطس 91 (إلى 000 دولار أمريكي). في عام 2022 ، قمنا أيضًا بتلخيص ما تعلمناه حتى الآن في كتاب الطبخ الخاص بنا وقدمنا وسائل التخفيف التجريبية لتقنيات التعدين الأكثر شيوعًا.
العام الماضيلتحسين أمان kernel من Linux المستخدم في البيئة المرجعية التي تم فيها إنتاج الاستغلال الذي يدعي الجائزة ، طبقت Google تعديلات وتصحيحات إضافية لمنع الأساليب النموذجية للاستغلال. على سبيل المثال ، تمت إضافة الحماية من الفساد إلى بنية القائمة المستقلة ، وتم حظر الكتابة خارج الحدود على اللوح ، وتم تنفيذ هجمات منع الهجمات المتعلقة بمشاركة ذاكرة التخزين المؤقت. لكن هذه التغييرات لم تؤثر على القدرة على استغلال الثغرات الأمنية في io_uring ، الأمر الذي دفع Google إلى التوقف عن دعم تقنية المعلومات في منتجاتها.
بينما يوفر io_uring مزايا أداء ويتفاعل بسرعة مع مشكلات الأمان من خلال إصلاحات الأمان الشاملة (مثل backporting 5.15 إلى الشجرة الثابتة 5.10) ، فهو جزء جديد إلى حد ما من النواة. على هذا النحو ، يستمر تطوير io_uring بنشاط ، لكنه لا يزال متأثرًا بنقاط ضعف خطيرة ويوفر أيضًا برمجيات إكسبلويت الأولية القوية. لهذه الأسباب ، نعتبرها حاليًا آمنة للمكونات الموثوقة فقط.
في نظام التشغيل ChromeOS ، يتم تعطيل دعم io_uring عند تجميع النواة (CONIFG_IO_URING في kernelconfig). يستخدم Android مؤقتًا مرشحًا يستند إلى seccomp-bpf لحظر الوصول إلى io_uring ويخطط لاستخدام SELinux لتقييد الوصول بشكل انتقائي إلى io_uring لمكونات النظام الموثوقة في إصدار مستقبلي.
على هذا النحو ، لا تأخذ Google وجهة نظر قاتمة لـ واجهة io_uring ، التي قدمتها نواة لينكس منذ الإصدار 5.1 ، لأنها تذكر أنه من بين نقاطها الإيجابية ، تبرز لدعمها لاقتراع الإدخال / الإخراج والقدرة على العمل مع أو بدون التخزين المؤقت ، ولكن على هذا النحو ، فهي لا تزال قوية بما يكفي لمواصلة تحمل المخاطر ، وقبل كل شيء ، مواصلة الاستثمار في إصلاح الأخطاء ونقاط الضعف التي تظهر باستمرار.
باستخدام io_uring API ، حاول مطورو kernel معالجة أوجه القصور في واجهة aio القديمة.
من حيث الأداء ، io_uring قريب جدًا من SPDK ويتفوق بشكل كبير على libaio عندما يتم تمكين الاقتراع. على سبيل المثال ، أدى استخدام io_uring في مكتبة libuv إلى زيادة في الأداء بمقدار 8 أضعاف ، كما أدى إدراج التخزين المؤقت للكتابة غير المتزامن المستند إلى io_uring في نظام ملفات XFS إلى تقليل زمن الانتقال بمقدار 80 ضعفًا وزيادة نقل البيانات بمقدار 2,7 ضعفًا. معدل.
ومن الجدير بالذكر أنه بالإضافة إلى ذلك ، تدرس Google إمكانية تعطيل io_uring افتراضيًا في GKE AutoPilot (Google Kubernetes Engine).
أخيرًا ، إذا كنت مهتمًا بمعرفة المزيد عنها ، يمكنك الرجوع إلى التفاصيل في الرابط التالي.