لتحسين أمان الجهاز، يقوم Android 7.0 بتقسيم عملية mediaserver المتجانسة إلى عمليات متعددة مع أذونات وإمكانيات مقيدة فقط بتلك التي تتطلبها كل عملية. تعمل هذه التغييرات على تخفيف الثغرات الأمنية لإطار عمل الوسائط من خلال:
- تقسيم مكونات خط أنابيب AV إلى عمليات وضع الحماية الخاصة بالتطبيق.
- تمكين مكونات الوسائط القابلة للتحديث (أدوات الاستخراج وبرامج الترميز وما إلى ذلك).
تعمل هذه التغييرات أيضًا على تحسين الأمان للمستخدمين النهائيين من خلال تقليل خطورة معظم الثغرات الأمنية المتعلقة بالوسائط بشكل كبير، والحفاظ على أمان أجهزة المستخدم النهائي وبياناته.
يحتاج مصنعو المعدات الأصلية وبائعو SoC إلى تحديث تغييرات HAL وإطار العمل الخاصة بهم لجعلها متوافقة مع البنية الجديدة. على وجه التحديد، نظرًا لأن تعليمات Android البرمجية المقدمة من البائع غالبًا ما تفترض أن كل شيء يعمل في نفس العملية، يجب على البائعين تحديث التعليمات البرمجية الخاصة بهم لتمرير المقابض الأصلية ( native_handle ) التي لها معنى عبر العمليات. للحصول على مرجع للتنفيذ للتغييرات المتعلقة بتقوية الوسائط، راجع frameworks/av و frameworks/native .
التغييرات المعمارية
استخدمت الإصدارات السابقة من Android عملية mediaserver واحدة متجانسة مع العديد من الأذونات (الوصول إلى الكاميرا، الوصول إلى الصوت، الوصول إلى برنامج تشغيل الفيديو، الوصول إلى الملفات، الوصول إلى الشبكة، وما إلى ذلك). يقسم Android 7.0 عملية mediaserver إلى عدة عمليات جديدة تتطلب كل منها مجموعة أصغر بكثير من الأذونات:
الشكل 1. تغييرات في البنية لتقوية خادم الوسائط
تضمن هذه البنية الجديدة أنه حتى لو تم اختراق العملية، فلن تتمكن التعليمات البرمجية الضارة من الوصول إلى مجموعة الأذونات الكاملة التي كانت مملوكة مسبقًا بواسطة mediaserver . العمليات مقيدة بسياسات SElinux وseccomp.
ملاحظة: بسبب تبعيات البائع، لا تزال بعض برامج الترميز تعمل في mediaserver وبالتالي تمنح mediaserver أذونات أكثر من اللازم. على وجه التحديد، يستمر Widevine Classic في العمل في mediaserver لنظام Android 7.0.
تغييرات خادم الوسائط
في Android 7.0، توجد عملية mediaserver لتشغيل التشغيل والتسجيل، على سبيل المثال، تمرير ومزامنة المخازن المؤقتة بين المكونات والعمليات. تتواصل العمليات من خلال آلية Binder القياسية.
في جلسة تشغيل الملفات المحلية القياسية، يقوم التطبيق بتمرير واصف الملف (FD) إلى mediaserver (عادة عبر MediaPlayer Java API)، mediaserver :
- يقوم بتغليف FD في كائن Binder DataSource الذي يتم تمريره إلى عملية الاستخراج، والتي تستخدمه للقراءة من الملف باستخدام Binder IPC. (لا يحصل مستخرج الوسائط على FD ولكنه يقوم بدلاً من ذلك بإجراء مكالمات Binder مرة أخرى إلى
mediaserverللحصول على البيانات.) - يقوم بفحص الملف، وإنشاء المستخرج المناسب لنوع الملف (على سبيل المثال، MP3Extractor أو MPEG4Extractor)، وإرجاع واجهة Binder للمستخرج إلى عملية
mediaserver. - يقوم بإجراء استدعاءات Binder IPC للمستخرج لتحديد نوع البيانات الموجودة في الملف (مثل بيانات MP3 أو H.264).
- استدعاء عملية
mediacodecلإنشاء برامج ترميز من النوع المطلوب؛ يتلقى واجهات Binder لبرامج الترميز هذه. - إجراء استدعاءات متكررة لـ Binder IPC إلى المستخرج لقراءة العينات المشفرة، واستخدام Binder IPC لإرسال البيانات المشفرة إلى عملية
mediacodecلفك التشفير، واستقبال البيانات التي تم فك تشفيرها.
في بعض حالات الاستخدام، لا يتم تضمين أي برنامج ترميز (مثل التشغيل غير المحمل حيث يتم إرسال البيانات المشفرة مباشرة إلى جهاز الإخراج)، أو قد يعرض برنامج الترميز البيانات التي تم فك تشفيرها مباشرة بدلاً من إرجاع مخزن مؤقت للبيانات التي تم فك تشفيرها (تشغيل الفيديو).
تغييرات MediaCodecService
خدمة الترميز هي المكان الذي تعيش فيه أجهزة التشفير وأجهزة فك التشفير. نظرًا لتبعيات البائع، لا توجد جميع برامج الترميز في عملية الترميز حتى الآن. في أندرويد 7.0:
- توجد وحدات فك التشفير وبرامج تشفير البرامج غير الآمنة في عملية الترميز.
- توجد وحدات فك التشفير الآمنة وأجهزة تشفير الأجهزة في
mediaserver(دون تغيير).
يستدعي التطبيق (أو mediaserver ) عملية برنامج الترميز لإنشاء برنامج ترميز من النوع المطلوب، ثم يستدعي برنامج الترميز هذا لتمرير البيانات المشفرة واسترداد البيانات التي تم فك تشفيرها (لفك التشفير) أو لتمرير البيانات التي تم فك تشفيرها واسترداد البيانات المشفرة (للتشفير) . يستخدم نقل البيانات من وإلى برامج الترميز ذاكرة مشتركة بالفعل، لذا لم تتغير هذه العملية.
تغييرات MediaDrmServer
يتم استخدام خادم DRM عند تشغيل محتوى محمي بموجب إدارة الحقوق الرقمية، مثل الأفلام في أفلام Google Play. فهو يتعامل مع فك تشفير البيانات المشفرة بطريقة آمنة، وبالتالي يمكنه الوصول إلى الشهادة وتخزين المفاتيح والمكونات الحساسة الأخرى. نظرًا لتبعيات البائع، لم يتم استخدام عملية إدارة الحقوق الرقمية (DRM) في جميع الحالات حتى الآن.
تغييرات خادم الصوت
تستضيف عملية AudioServer المكونات المتعلقة بالصوت مثل إدخال الصوت وإخراجه، وخدمة إدارة السياسات التي تحدد توجيه الصوت، وخدمة راديو FM. للحصول على تفاصيل حول تغييرات الصوت وإرشادات التنفيذ، راجع تنفيذ الصوت .
تغييرات خادم الكاميرا
يتحكم CameraServer في الكاميرا ويستخدم عند تسجيل الفيديو للحصول على إطارات فيديو من الكاميرا ثم تمريرها إلى mediaserver لمزيد من المعالجة. للحصول على تفاصيل حول التغييرات وإرشادات التنفيذ لتغييرات CameraServer، راجع Camera Framework Hardening .
تغييرات ExtractorService
تستضيف خدمة المستخرج المستخرجات ، وهي المكونات التي تحلل تنسيقات الملفات المختلفة التي يدعمها إطار عمل الوسائط. خدمة الاستخراج هي الأقل امتيازًا بين جميع الخدمات - فهي لا تستطيع قراءة FDs، لذا فهي تقوم بدلاً من ذلك بإجراء مكالمات على واجهة Binder (التي يوفرها لها mediaserver for لكل جلسة تشغيل) للوصول إلى الملفات.
يقوم أحد التطبيقات (أو mediaserver ) باستدعاء عملية الاستخراج للحصول على IMediaExtractor ، واستدعاء IMediaExtractor للحصول على IMediaSources للمسار الموجود في الملف، ثم استدعاء IMediaSources لقراءة البيانات منها.
لنقل البيانات بين العمليات، يتضمن التطبيق (أو mediaserver ) البيانات الموجودة في حزمة الرد كجزء من معاملة Binder أو يستخدم الذاكرة المشتركة:
- يتطلب استخدام الذاكرة المشتركة استدعاء Binder إضافيًا لتحرير الذاكرة المشتركة ولكنه أسرع ويستخدم طاقة أقل للمخازن المؤقتة الكبيرة.
- يتطلب استخدام in-Parcel نسخًا إضافيًا ولكنه أسرع ويستخدم طاقة أقل للمخازن المؤقتة الأصغر من 64 كيلو بايت.
تطبيق
لدعم نقل مكونات MediaDrm و MediaCrypto إلى عملية mediadrmserver الجديدة، يجب على البائعين تغيير طريقة التخصيص للمخازن المؤقتة الآمنة للسماح بمشاركة المخازن المؤقتة بين العمليات.
في إصدارات Android السابقة، يتم تخصيص المخازن المؤقتة الآمنة في mediaserver بواسطة OMX::allocateBuffer ويتم استخدامها أثناء فك التشفير في نفس العملية، كما هو موضح أدناه:
الشكل 2. Android 6.0 وتخصيص المخزن المؤقت الأقل في خادم الوسائط.
في Android 7.0، تغيرت عملية تخصيص المخزن المؤقت إلى آلية جديدة توفر المرونة مع تقليل التأثير على التطبيقات الحالية. باستخدام مكدسات MediaDrm و MediaCrypto في عملية mediadrmserver الجديدة، يتم تخصيص المخازن المؤقتة بشكل مختلف ويجب على البائعين تحديث مقابض المخزن المؤقت الآمنة بحيث يمكن نقلها عبر الرابط عندما يستدعي MediaCodec عملية فك التشفير على MediaCrypto .
الشكل 3. تخصيص المخزن المؤقت لنظام Android 7.0 والإصدارات الأعلى في خادم الوسائط.
استخدم المقابض الأصلية
يجب أن يقوم OMX::allocateBuffer بإرجاع مؤشر إلى بنية native_handle ، والتي تحتوي على واصفات الملفات (FDs) وبيانات عدد صحيح إضافية. يتمتع native_handle بجميع مزايا استخدام FDs، بما في ذلك دعم الموثق الحالي للتسلسل/إلغاء التسلسل، مع السماح بمزيد من المرونة للبائعين الذين لا يستخدمون FDs حاليًا.
استخدم native_handle_create() لتخصيص المقبض الأصلي. يأخذ كود إطار العمل ملكية بنية native_handle المخصصة ويكون مسؤولاً عن تحرير الموارد في كل من العملية حيث تم تخصيص native_handle في الأصل وفي العملية التي يتم فيها إلغاء تسلسلها. يُطلق إطار العمل المقابض الأصلية باستخدام native_handle_close() متبوعة بـ native_handle_delete() ويقوم بإجراء تسلسل/إلغاء native_handle باستخدام Parcel::writeNativeHandle()/readNativeHandle() .
يمكن لبائعي SoC الذين يستخدمون FDs لتمثيل المخازن المؤقتة الآمنة ملء FD في native_handle باستخدام FD الخاص بهم. يمكن للموردين الذين لا يستخدمون FDs تمثيل مخازن مؤقتة آمنة باستخدام حقول إضافية في native_buffer .
تحديد موقع فك التشفير
يجب على البائعين تحديث طريقة فك تشفير OEMCrypto التي تعمل على native_handle لتنفيذ أي عمليات خاصة بالمورد ضرورية لجعل native_handle قابلاً للاستخدام في مساحة العملية الجديدة (تتضمن التغييرات عادةً تحديثات لمكتبات OEMCrypto).
نظرًا لأن allocateBuffer عبارة عن عملية OMX قياسية، فإن Android 7.0 يتضمن ملحق OMX جديدًا ( OMX.google.android.index.allocateNativeHandle ) للاستعلام عن هذا الدعم واستدعاء OMX_SetParameter الذي يُعلم تنفيذ OMX بأنه يجب أن يستخدم المقابض الأصلية.