ميكرودرويد

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

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

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

سمات

يعد Microdroid إصدارًا مُجردًا من نظام التشغيل Android مع بعض المكونات الإضافية الخاصة بـ pVMs. يدعم Microdroid:

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

لا يدعم Microdroid:

• Android Java APIs في حزم android.\*

• SystemServer و Zygote

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

• HALs

بنية Microdroid

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

• bootloader - يتحقق من النواة ويبدأ تشغيلها.
• boot.img - يحتوي على kernel و init ramdisk.
• vendor\_boot.img - يحتوي على وحدات kernel الخاصة بـ VM ، مثل Virtio.
• super.img - يتكون من أقسام منطقية للنظام والبائع.
• vbmeta.img - يحتوي على بيانات تعريف تمهيد تم التحقق منها.

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

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

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

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

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

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

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

   ثم يقوم برنامج bootloader بتشغيل Microdroid.

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

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

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

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

6. تبدأ خدمة مدير apexd في القمة.

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

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

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

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

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

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

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

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

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

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

Binder RPC

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

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