ميكرودرويد

Microdroid هو نظام تشغيل Android صغير يعمل في pVM. ليس عليك استخدام Microdroid، يمكنك تشغيل جهاز افتراضي مع أي نظام تشغيل. ومع ذلك، فإن حالات الاستخدام الأساسية لـ pVMs لا تعمل بنظام تشغيل مستقل، بل تقدم بيئة تنفيذ معزولة لتشغيل جزء من التطبيق مع ضمانات سرية ونزاهة أقوى مما يمكن أن يوفره Android.

مع أنظمة التشغيل التقليدية، يتطلب توفير السرية والنزاهة القوية قدرًا لا بأس به من العمل (غالبًا ما يكون مكررًا) لأن أنظمة التشغيل التقليدية لا تتناسب مع بنية Android الشاملة. على سبيل المثال، باستخدام بنية Android القياسية، يحتاج المطورون إلى تنفيذ وسيلة لتحميل وتنفيذ جزء من تطبيقهم بشكل آمن في pVM، ويتم إنشاء الحمولة مقابل glibc. يستخدم تطبيق Android Bionic، ويتطلب الاتصال بروتوكولًا مخصصًا عبر vsock، كما يمثل تصحيح الأخطاء باستخدام adb تحديًا.

يملأ Microdroid هذه الفجوات من خلال توفير صورة نظام تشغيل جاهزة مصممة لتتطلب أقل قدر من الجهد من المطورين لتفريغ جزء من تطبيقاتهم في pVM. تم إنشاء الكود الأصلي ضد Bionic، ويتم الاتصال عبر Binder، ويسمح باستيراد APEXes من Android ويكشف عن مجموعة فرعية من Android API، مثل مخزن المفاتيح لعمليات التشفير باستخدام المفاتيح المدعومة بالأجهزة. بشكل عام، يجب على المطورين أن يجدوا Microdroid بيئة مألوفة مع الأدوات التي اعتادوا عليها في نظام التشغيل Android الكامل.

سمات

Microdroid هو إصدار مبسط من Android مع بعض المكونات الإضافية الخاصة بـ pVMs. يدعم مايكرودرويد:

  • مجموعة فرعية من واجهات برمجة تطبيقات NDK (يتم توفير جميع واجهات برمجة التطبيقات لتطبيق Android لـ libc وBionic)
  • ميزات التصحيح، مثل adb، وlogcat، وTombstone، وgdb
  • تم تمكين التمهيد الذي تم التحقق منه وSELinux
  • تحميل وتنفيذ ملف ثنائي، مع المكتبات المشتركة، المضمنة في ملف APK
  • Binder RPC عبر vsock وتبادل الملفات مع اختبارات السلامة الضمنية
  • تحميل APEXes

ميكرودرويد لا يدعم:

  • واجهات برمجة تطبيقات Android Java في حزم android.\*

  • خادم النظام و Zygote

  • الرسومات / واجهة المستخدم

  • هال

بنية مايكرودرويد

يشبه Microdroid تطبيق Cuttlefish من حيث أن كلاهما يتمتع ببنية مشابهة لنظام Android القياسي. يتكون Microdroid من صور الأقسام التالية المجمعة معًا في صورة قرص مركبة:

  • bootloader - تتحقق من النواة وتبدأ تشغيلها.
  • boot.img - يحتوي على النواة وقرص ذاكرة الوصول العشوائي.
  • vendor_boot.img - يحتوي على وحدات kernel الخاصة بالجهاز الظاهري، مثل Virtio.
  • super.img - يتكون من أقسام منطقية للنظام والبائعين.
  • vbmeta.img - يحتوي على بيانات تعريف التمهيد التي تم التحقق منها.

يتم شحن صور القسم في Virtualization APEX ويتم تجميعها في صورة قرص مركبة بواسطة VirtualizationService . بالإضافة إلى صورة القرص المركب لنظام التشغيل الرئيسي، تكون VirtualizationService مسؤولة عن إنشاء هذه الأقسام الأخرى:

  • payload - مجموعة من الأقسام المدعومة بـ APEXes وAPK لنظام Android
  • instance - قسم مشفر لاستمرار بيانات التمهيد التي تم التحقق منها لكل مثيل، مثل الملح لكل مثيل، ومفاتيح APEX العامة الموثوقة، وعدادات التراجع

تسلسل التمهيد

يحدث تسلسل تمهيد Microdroid بعد تمهيد الجهاز . تمت مناقشة تمهيد الجهاز في مستند البنية . يوضح الشكل 1 الخطوات التي تحدث أثناء تسلسل تمهيد Microdroid:

تأمين التمهيد لمثيل microdroid

الشكل 1. تدفق التمهيد الآمن لمثيل microdroid

وفيما يلي شرح للخطوات:

  1. يتم تحميل أداة تحميل التشغيل في الذاكرة عن طريق crosvm ويبدأ تنفيذ pvmfw. قبل الانتقال إلى أداة تحميل التشغيل، يقوم pvmfw بمهمتين:

    • التحقق من أداة تحميل التشغيل للتحقق مما إذا كانت من مصدر موثوق به (Google أو OEM).
    • يضمن استخدام نفس أداة تحميل التشغيل بشكل متسق عبر عمليات تمهيد متعددة لنفس pVM من خلال استخدام صورة المثيل. على وجه التحديد، يتم تمهيد pVM مبدئيًا بصورة مثيل فارغة. يقوم pvmfw بتخزين هوية أداة تحميل التشغيل في صورة المثيل ويقوم بتشفيرها. لذلك، في المرة التالية التي يتم فيها تشغيل pVM بنفس صورة المثيل، يقوم pvmfw بفك تشفير الهوية المحفوظة من صورة المثيل والتحقق من أنها هي نفسها التي تم حفظها مسبقًا. إذا اختلفت الهويات، يرفض pvmfw التمهيد.

    يقوم أداة تحميل التشغيل بعد ذلك بتمهيد Microdroid.

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

  3. يتحقق محمل الإقلاع من vbmeta والأقسام المتسلسلة، مثل boot و super ، وإذا نجح، فإنه يستمد أسرار pVM للمرحلة التالية. بعد ذلك، يقوم Microdroid بتسليم التحكم إلى النواة.

  4. نظرًا لأنه تم بالفعل التحقق من القسم الفائق بواسطة أداة تحميل التشغيل (الخطوة 3)، تقوم النواة بتثبيت القسم الفائق دون قيد أو شرط. كما هو الحال مع نظام Android الكامل، يتكون القسم الفائق من أقسام منطقية متعددة مثبتة على dm-verity. يتم بعد ذلك تمرير التحكم إلى عملية init ، التي تبدأ العديد من الخدمات الأصلية. يشبه البرنامج النصي init.rc البرنامج النصي لنظام Android الكامل ولكنه مصمم خصيصًا لتلبية احتياجات Microdroid.

  5. تبدأ عملية init مدير Microdroid، الذي يصل إلى صورة المثيل. تقوم خدمة Microdroid manager بفك تشفير الصورة باستخدام المفتاح الذي تم تمريره من المرحلة السابقة وتقرأ المفاتيح العامة وعدادات التراجع الخاصة بالعميل APK وAPEXes التي يثق بها pVM. يتم استخدام هذه المعلومات لاحقًا بواسطة zipfuse و apexd عند قيامهما بتثبيت APK العميل وطلب APEXes، على التوالي.

  6. تبدأ خدمة مدير Microdroid apexd .

  7. يقوم apexd بتثبيت APEXes في الدلائل /apex/<name> . الفرق الوحيد بين كيفية تثبيت Android وMicrodroid APEXes هو أنه في Microdroid، تأتي ملفات APEX من أجهزة الحظر الافتراضية ( /dev/vdc1 ، ...)، وليس من الملفات العادية ( /system/apex/*.apex ).

  8. zipfuse هو نظام ملفات FUSE الخاص بـ Microdroid. يقوم zipfuse بتثبيت ملف APK الخاص بالعميل، وهو في الأساس ملف مضغوط كنظام ملفات. وفي الأسفل، يتم تمرير ملف APK كجهاز كتلة افتراضي بواسطة pVM باستخدام dm-verity، مثل APEX. يحتوي APK على ملف تكوين يحتوي على قائمة بـ APEXes التي طلبها مطور التطبيق لمثيل pVM هذا. يتم استخدام القائمة بواسطة apexd عند تنشيط APEXes.

  9. يعود تدفق التمهيد إلى خدمة مدير Microdroid. تتواصل خدمة المدير بعد ذلك مع VirtualizationService لنظام Android باستخدام Binder RPC حتى تتمكن من الإبلاغ عن الأحداث المهمة مثل الأعطال أو إيقاف التشغيل، وقبول الطلبات مثل إنهاء pVM. تقرأ خدمة المدير موقع الملف الثنائي الرئيسي من ملف التكوين الخاص بـ APK وتنفذه.

تبادل الملفات (AuthFS)

من الشائع أن تستخدم مكونات Android ملفات للإدخال والإخراج والحالة وتمريرها كواصفات ملفات (نوع ParcelFileDescriptor في AIDL) مع التحكم في الوصول بواسطة Android kernel. يقوم AuthFS بتسهيل وظائف مماثلة لتبادل الملفات بين نقاط النهاية التي لا تثق بشكل متبادل عبر حدود pVM.

في الأساس، AuthFS هو نظام ملفات بعيد يتمتع بفحوصات سلامة شفافة لعمليات الوصول الفردية، على غرار fs-verity . تسمح عمليات التحقق للواجهة الأمامية، مثل برنامج قراءة الملفات الذي يعمل في pVM، باكتشاف ما إذا كانت الواجهة الخلفية غير الموثوق بها، عادةً Android، قد تلاعبت بمحتوى الملف.

لتبادل الملفات، يتم تشغيل الواجهة الخلفية ( fd\_server ) بتكوين لكل ملف يحدد ما إذا كان مخصصًا للإدخال (للقراءة فقط) أو الإخراج (للقراءة والكتابة). بالنسبة للإدخال، تفرض الواجهة الأمامية أن تتطابق المحتويات مع تجزئة معروفة، أعلى شجرة Merkle للتحقق عند الوصول. بالنسبة للمخرجات، يحتفظ AuthFS داخليًا بشجرة تجزئة للمحتويات كما تمت ملاحظتها من عمليات الكتابة ويمكنه فرض التكامل عند إعادة قراءة البيانات.

يعتمد النقل الأساسي حاليًا على Binder RPC، ومع ذلك قد يتغير ذلك في المستقبل لتحسين الأداء.

ادارة المفاتيح

يتم تزويد pVMs بمفتاح إغلاق ثابت مناسب للبيانات المستمرة المحمية، ومفتاح تصديق مناسب لإنتاج التوقيعات التي يتم إنتاجها بشكل يمكن التحقق منه بواسطة pVM.

الموثق RPC

يتم التعبير عن غالبية واجهات Android في AIDL ، والتي تم إنشاؤها أعلى برنامج تشغيل Binder Linux kernel. لدعم الواجهات بين pVMs، تمت إعادة كتابة بروتوكول Binder للعمل عبر المقابس، vsock في حالة pVMs. يتيح التشغيل عبر المقابس استخدام واجهات AIDL الموجودة في Android في هذه البيئة الجديدة.

لإعداد الاتصال، تقوم نقطة نهاية واحدة، مثل حمولة pVM، بإنشاء كائن RpcServer ، وتسجيل كائن جذر، والبدء في الاستماع للاتصالات الجديدة. يمكن للعملاء الاتصال بهذا الخادم باستخدام كائن RpcSession ، والحصول على كائن Binder ، واستخدامه تمامًا كما يتم استخدام كائن Binder مع برنامج تشغيل kernel Binder.