اقترح أحد مطوري Google حماية ضد هجمات LVI

قبل بضعة أيام تحدثنا هنا في المدونة عن LVI ، التي تصنف على أنها سلسلة جديدة من الهجمات التي تؤثر فقط على وحدات المعالجة المركزية Intel وتتميز بكونها سلسلة من الهجمات التي تعتمد على التلاعب بنفس الهياكل المعمارية الدقيقة كما هو الحال في هجمات MDS و Specter و Meltdown.

الفرق الرئيسي بين أنا أهاجمهمs LVI و MDS هو أن MDS يتلاعب في تحديد المحتوى للهياكل المعمارية الدقيقة التي تظل في ذاكرة التخزين المؤقت بعد معالجة الأخطاء التخمينية أو عمليات التحميل والتخزين ، في حين الهجمات يسمح LVI باستبدال المهاجم في الهياكل المعمارية الدقيقة للتأثير على التنفيذ التخميني اللاحق لقانون الضحية.

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

المادة ذات الصلة:
LVI: فئة جديدة من هجمات التنفيذ التخمينية على وحدات المعالجة المركزية Intel

وعلاوة على ذلك، جسور زولا (مطور جوجل) كان يعمل على هذه المشكلة وعرض مؤخرًا تصحيحًا للمترجم LLVM مع حماية SESES (قمع التأثيرات الجانبية للتنفيذ التخميني) التي تساعد على منع الهجمات على محركات تنفيذ تخمينية محددة تؤثر على وحدات المعالجة المركزية Intel مثل LVIs.

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

يتكون التخفيف من خطوة المترجم التي تُدرج LFENCE من قبل
كل ذاكرة قراءة التعليمات ، وكتابة الذاكرة التعليمات والأول
بيان الفرع على مجموعة من النهايات في نهاية
كتلة أساسية. 

تتوقع تعليمات LFENCE تأكيد جميع القراءات السابقة من الذاكرة و لا يسمح بالتنفيذ الاستباقي للتعليمات التي تتبع LFENCE قبل اكتمال التأكيد.

استخدام LFENCE يؤدي إلى انخفاض كبير في الأداء ، هكذا، يقترح استخدام الحماية في الحالات القصوى للرموز الهامة بشكل خاص. بالإضافة إلى الحماية الكاملة ، يقدم التصحيح ثلاثة علامات تعطل بشكل انتقائي مستويات معينة من الحماية لتقليل التأثير السلبي على الأداء.

في اختباراتنا ، أدى استخدام حماية SESES لحزمة BoringSSL إلى انخفاض بمقدار 14 ضعفًا في عدد العمليات التي تقوم بها المكتبة في الثانية - تبين أن أداء نسخة المكتبة المجمعة مع الحماية كان في المتوسط ​​فقط أداء 7.1٪ من الإصدار غير المحمي (يمتد اعتمادًا على الاختبار من 4٪ إلى 23٪)

بالإضافة إلى الإصدار الكامل من التخفيف ، يقوم هذا التصحيح بتنفيذ ثلاث إشارات لتعطيل جزء من التخفيف.

يتم تعطيل هذه العلامات افتراضيًا. لا يُقصد من العلامات أن تؤدي إلى متغير آمن للتخفيف. تهدف المؤشرات إلى استخدامها من قبل المستخدمين الذين يرغبون في التجربة لتحسين أداء
تخفيف.

للمقارنة، الآلية المقترحة مسبقًا لـ GNU Assembler، والتي تقوم باستبدال LFENCE بعد كل عملية تحميل من الذاكرة وقبل بعض تعليمات التفريع ، أظهرت انخفاضًا في الأداء بنحو 5 مرات (22٪ من الكود بدون حماية).

طريقة الحماية أيضا تم اقتراحه وتنفيذه من قبل مهندسي إنتل، ولكن نتائج اختبار الأداء لم يتم الإفراج عنها بعد. في البداية ، توقع الباحثون الذين اكتشفوا هجوم LVI انخفاضًا بمقدار 2-19 ضعفًا في الأداء عند تطبيق الحماية الكاملة.

أخيرًا ، إذا كنت تريد معرفة المزيد عنها ، فيمكنك التحقق من التفاصيل في الرابط التالي. 


كن أول من يعلق

اترك تعليقك

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها ب *

*

*

  1. المسؤول عن البيانات: ميغيل أنخيل جاتون
  2. الغرض من البيانات: التحكم في الرسائل الاقتحامية ، وإدارة التعليقات.
  3. الشرعية: موافقتك
  4. توصيل البيانات: لن يتم إرسال البيانات إلى أطراف ثالثة إلا بموجب التزام قانوني.
  5. تخزين البيانات: قاعدة البيانات التي تستضيفها شركة Occentus Networks (الاتحاد الأوروبي)
  6. الحقوق: يمكنك في أي وقت تقييد معلوماتك واستعادتها وحذفها.