تصلب إطار الوسائط

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

لتحسين أمان الجهاز ، يقوم Android 7.0 بتقسيم عملية mediaserver الأحادي إلى عمليات متعددة بأذونات وإمكانيات تقتصر فقط على تلك التي تتطلبها كل عملية. تخفف هذه التغييرات من الثغرات الأمنية في إطار عمل الوسائط من خلال:

  • تقسيم مكونات خطوط أنابيب AV إلى عمليات آلية خاصة بالتطبيق.
  • تمكين مكونات الوسائط القابلة للتحديث (برامج الاستخراج وبرامج الترميز وما إلى ذلك).

تعمل هذه التغييرات أيضًا على تحسين الأمان للمستخدمين النهائيين عن طريق الحد بشكل كبير من شدة معظم الثغرات الأمنية المتعلقة بالوسائط ، والحفاظ على أجهزة المستخدم النهائي والبيانات آمنة.

يحتاج بائعو OEM و SoC إلى تحديث HAL وتغييرات إطار العمل لجعلها متوافقة مع البنية الجديدة. على وجه التحديد ، نظرًا لأن كود Android المقدم من البائع غالبًا ما يفترض أن كل شيء يعمل في نفس العملية ، يجب على البائعين تحديث native_handle لتمرير المقابض الأصلية (original_handle) التي لها معنى عبر العمليات. للحصول على تنفيذ مرجعي للتغييرات المتعلقة بتصلب الوسائط ، ارجع إلى frameworks/av frameworks/native .

التغييرات المعمارية

استخدمت الإصدارات السابقة من Android عملية mediaserver واحدة متجانسة مع العديد من الأذونات (الوصول إلى الكاميرا ، والوصول إلى الصوت ، والوصول إلى برنامج تشغيل الفيديو ، والوصول إلى الملفات ، والوصول إلى الشبكة ، وما إلى ذلك). يقسم Android 7.0 عملية mediaserver إلى عدة عمليات جديدة تتطلب كل منها مجموعة أصغر من الأذونات:

تصلب mediaserver

الشكل 1. تغييرات معمارية لتصلب خادم الوسائط

تضمن هذه البنية الجديدة أنه حتى في حالة تعرض العملية للخطر ، فإن التعليمات البرمجية الضارة لا يمكنها الوصول إلى المجموعة الكاملة من الأذونات التي كان يمتلكها خادم الوسائط مسبقًا. العمليات مقيدة بسياسات SElinux و seccomp.

ملاحظة: بسبب تبعيات البائع ، لا تزال بعض برامج الترميز تعمل في mediaserver وبالتالي تمنح mediaserver أذونات أكثر من اللازم. على وجه التحديد ، يستمر mediaserver Classic في العمل في خادم الوسائط لنظام Android 7.0.

تغييرات MediaServer

في Android 7.0 ، توجد عملية mediaserver لقيادة التشغيل والتسجيل ، مثل تمرير ومزامنة المخازن المؤقتة بين المكونات والعمليات. تتواصل العمليات من خلال آلية Binder القياسية.

في جلسة تشغيل ملف محلي قياسي ، يمرر التطبيق واصف ملف (FD) إلى خادم الوسائط (عادةً عبر mediaserver Java API) ، mediaserver :

  1. يلتف ملف FD ​​في كائن مصدر بيانات Binder الذي يتم تمريره إلى عملية الاستخراج ، والذي يستخدمه للقراءة من الملف باستخدام Binder IPC. (لا يحصل مستخرج الوسائط على FD ولكنه بدلاً من ذلك يقوم بإجراء مكالمات Binder مرة أخرى إلى mediaserver للحصول على البيانات.)
  2. يفحص الملف ، وينشئ المستخرج المناسب لنوع الملف (مثل MP3Extractor ، أو MPEG4Extractor) ، ويعيد واجهة Binder للمستخرج إلى عملية mediaserver .
  3. يقوم بإجراء مكالمات Binder IPC للمستخرج لتحديد نوع البيانات في الملف (مثل بيانات MP3 أو H.264).
  4. يدعو إلى عملية mediacodec لإنشاء برامج ترميز من النوع المطلوب ؛ يتلقى واجهات Binder لبرامج الترميز هذه.
  5. يجعل مكالمات Binder IPC متكررة إلى المستخرج لقراءة العينات المشفرة ، ويستخدم Binder IPC لإرسال البيانات المشفرة إلى عملية mediacodec لفك التشفير ، واستقبال البيانات التي تم فك تشفيرها.

في بعض حالات الاستخدام ، لا يتم تضمين أي برنامج ترميز (مثل تشغيل غير محمل حيث يتم إرسال البيانات المشفرة مباشرة إلى جهاز الإخراج) ، أو قد يعرض برنامج الترميز البيانات التي تم فك تشفيرها مباشرةً بدلاً من إرجاع مخزن مؤقت للبيانات التي تم فك تشفيرها (تشغيل الفيديو).

تغييرات MediaCodecService

خدمة الترميز هي المكان الذي تعيش فيه أجهزة التشفير وأجهزة فك التشفير. بسبب تبعيات البائع ، ليست كل برامج الترميز موجودة في عملية الترميز حتى الآن. في Android 7.0:

  • تعيش أجهزة فك التشفير وبرامج التشفير غير الآمنة في عملية الترميز.
  • تعيش أجهزة فك التشفير الآمنة وأجهزة ترميز الأجهزة في mediaserver (دون تغيير).

يستدعي أحد التطبيقات (أو خادم الوسائط) عملية الترميز لإنشاء برنامج ترميز من النوع المطلوب ، ثم يستدعي برنامج الترميز هذا لتمرير البيانات المشفرة واسترداد البيانات التي تم فك ترميزها (لفك التشفير) أو لتمرير البيانات التي تم فك تشفيرها واسترداد البيانات المشفرة (للتشفير) . يستخدم نقل البيانات من وإلى برامج الترميز ذاكرة مشتركة بالفعل ، لذلك لم تتغير هذه العملية.

تغييرات MediaDrmServer

يُستخدم خادم DRM عند تشغيل محتوى محمي بنظام إدارة الحقوق الرقمية ، مثل الأفلام الموجودة في أفلام Google Play. يتعامل مع فك تشفير البيانات المشفرة بطريقة آمنة ، وعلى هذا النحو لديه حق الوصول إلى الشهادة وتخزين المفاتيح والمكونات الحساسة الأخرى. نظرًا لاعتماد البائعين ، لم يتم استخدام عملية إدارة الحقوق الرقمية في جميع الحالات حتى الآن.

تغييرات خادم الصوت

تستضيف عملية AudioServer المكونات ذات الصلة بالصوت مثل إدخال الصوت ومخرجاته وخدمة إدارة السياسة التي تحدد توجيه الصوت وخدمة راديو FM. للحصول على تفاصيل حول التغييرات الصوتية وإرشادات التنفيذ ، راجع تنفيذ الصوت .

تغييرات CameraServer

يتحكم CameraServer في الكاميرا ويستخدم عند تسجيل الفيديو للحصول على إطارات الفيديو من الكاميرا ثم تمريرها إلى mediaserver لمزيد من المعالجة. للحصول على تفاصيل حول التغييرات وإرشادات التنفيذ لتغييرات CameraServer ، راجع Camera Framework Hardening .

تغييرات ExtractorService

تستضيف خدمة المستخرج المستخلصات والمكونات التي تحلل تنسيقات الملفات المختلفة التي يدعمها إطار عمل الوسائط. خدمة المستخرج هي الأقل امتيازًا بين جميع الخدمات - لا يمكنها قراءة ملفات FD ، لذا فهي تقوم بإجراء مكالمات على واجهة 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 .

تحديد موقع فك التشفير

يجب على البائعين تحديث طريقة فك تشفير native_handle التي تعمل على العنوان الأصلي لإجراء أي عمليات خاصة بالمورد ضرورية لجعل native_handle قابلة للاستخدام في مساحة العملية الجديدة (تتضمن التغييرات عادةً تحديثات لمكتبات OEMCrypto).

نظرًا لأن allocateBuffer عملية OMX قياسية ، فإن Android 7.0 يتضمن امتداد OMX جديدًا ( OMX.google.android.index.allocateNativeHandle ) للاستعلام عن هذا الدعم واستدعاء OMX_SetParameter الذي يخطر تطبيق OMX يجب أن يستخدم المقابض الأصلية.