يمكن تمكين MTE بشكل مستقل في نواة Android وفي أي عملية في نظام Android. لا تفرض Google أي تكوين محدد وتهدف إلى توفير أقصى قدر من المرونة لمنشئي الأجهزة.
يصف هذا المستند إعدادات ونطاق MTE الذي، في رأينا، يوفر مقايضة جيدة بين الأمان والتكلفة لمستخدمي Android كتخفيف دائم للثغرات الأمنية.
نواة
يتم تكوين MTE في النواة من خلال سطر الأوامر. الافتراضي هو ON في وضع المزامنة. وهذا عرضة للتغيير في المستقبل لعدة أسباب:
- لقد ثبت أنه يؤثر بشكل كبير على الأداء ويحتاج إلى تحسين العمل.
- يُنظر إلى جودة كود Kernel على نطاق واسع على أنها غير كافية لشحن MTE في وضع التنفيذ (أي الذعر عند الفشل).
التوصية الحالية هي تعطيل kernel MTE على أجهزة الإنتاج. للقيام بذلك، أضف kasan=off إلى سطر أوامر kernel.
مساحة المستخدم
توفر Google قائمة افتراضية بثنائيات مساحة المستخدم المراد حمايتها باستخدام MTE. تم تكوين القائمة باستخدام مدخلات من Android Security وتتضمن مكونات ذات امتيازات و/أو تتعامل مع مدخلات غير موثوقة. يمكن العثور على القائمة المحدثة للثنائيات الأصلية الموصى بها مع MTE في ملف memtag-common.mk في نظام بناء Android. بالإضافة إلى ذلك، يتم أيضًا تضمين العديد من تطبيقات النظام : حاليًا، NFC وBluetooth وSecureElement. يتم تمكين هذه الثنائيات والتطبيقات في الوضع غير المتزامن بشكل افتراضي.
التوصية الحالية هي استخدام قائمة الأهداف الافتراضية (لا يلزم إجراء تغييرات). بالإضافة إلى ذلك، يوصى بتقييم إضافات BSP وOEM إلى النظام الأساسي وتمكين MTE على الأنظمة الحساسة للأمان.
التطبيقات
تطبيقات النظام الثلاثة المذكورة أعلاه هي الوحيدة التي تستخدم MTE في الوقت الحالي. لكي يتمكن تطبيق طرف ثالث من تمكين MTE، سيحتاج AndroidManifest.xml الخاص به إلى تحديد android:memtagMode بقيمة أخرى غير off . وبالتالي، فإن مجموعات المعايير الشائعة مثل Geekbench أو AnTuTu لا تعمل مع MTE. إذا تم تعطيل kernel MTE أيضًا (راجع kasan=off أعلاه)، فمن المتوقع أن تُظهر المعايير تأثيرًا محدودًا للغاية على الأداء، إن وجد على الإطلاق.
أما بالنسبة للتطبيقات الأخرى، فهناك تطوير نشط لدعم MTE في Chrome. يتضمن الإصدار الحالي من متجر Play من Chrome إعداد memtagMode=async في البيان. ونتوقع أيضًا أن يقوم عدد من التطبيقات الأمنية في نظام Android البيئي (على سبيل المثال، التطبيقات المصرفية) بفعل الشيء نفسه في النهاية. ومن ناحية أخرى، نتوقع أن تختار بعض التطبيقات التي تتطلب أعلى أداء لوحدة المعالجة المركزية (CPU) مثل الألعاب إبقاء MTE معطلاً.
أوضاع أخرى
تستخدم الإرشادات المذكورة أعلاه وضع MTE غير المتزامن فقط في كل مكان. اعتمادًا على الجهاز، قد تكون الأوضاع الأخرى بنفس السرعة تقريبًا أو تمامًا. كما أنها توفر تشخيصًا أفضل وخصائص أقوى إلى حد ما لتخفيف الثغرات الأمنية.
نوصي باختبار تكوين واحد أو اثنين آخرين لمعرفة ما إذا كانت جيدة بما يكفي لمتطلبات الأداء/الطاقة لديك. يمكن ضبط أوضاع MTE لكل نواة وحدة المعالجة المركزية في النظام عن طريق الكتابة إلى /sys/devices/system/cpu/cpu*/mte_tcf_preferred . على سبيل المثال، قد تؤدي كتابة sync (أو asymm ) إلى ترقية أي عملية في مساحة المستخدم تطلب ترقية وضع Async تلقائيًا بصمت إلى Sync (أو Asymm) أثناء التشغيل على ذلك المركز. يمكن إجراء هذا الإعداد في ملف .rc أثناء تشغيل الجهاز.
نوصي بقياس تكوين واحد أو اثنين آخرين للتحقق مما إذا كانت تلبي متطلبات الأداء والطاقة الخاصة بك. بعض التكوينات المثيرة للاهتمام للاستكشاف:
- غير متماثل على جميع النوى.
- غير متماثل على النواة (المراكز) الكبيرة، والمزامنة على النوى الأخرى.
للتحقق من أن العملية تطلب الوضع غير المتزامن (مع إمكانية الترقية التلقائية)، تأكد من أن السطر التالي يتضمن كلاً من PR_MTE_TCF_SYNC و PR_MTE_TCF_ASYNC :
debuggerd| head -30 | grep tagged_addr
لسوء الحظ، لا توجد طريقة سهلة لرؤية الوضع الفعال لعملية ما؛ ولكن أي عملية تعرض كلا القيمتين المذكورتين أعلاه تخضع لسلوك الترقية التلقائية.