מיקרודרואיד

Microdroid היא מערכת הפעלה מיני אנדרואיד הפועלת ב-pVM. אתה לא צריך להשתמש ב-Microdroid, אתה יכול להפעיל VM עם כל מערכת הפעלה. עם זאת, מקרי השימוש העיקריים עבור pVMs אינם הפעלת מערכת הפעלה עצמאית אלא מציעים סביבת הפעלה מבודדת להפעלת חלק מאפליקציה עם הבטחות סודיות ושלמות חזקות יותר ממה ש-Android יכולה לספק.

עם מערכות הפעלה מסורתיות, אספקת סודיות ויושרה חזקים דורשת כמות לא מבוטלת של עבודה (לעתים קרובות משוכפלת) מכיוון שמערכות הפעלה מסורתיות אינן מתאימות לארכיטקטורת האנדרואיד הכוללת. לדוגמה, עם ארכיטקטורת אנדרואיד הסטנדרטית, מפתחים צריכים ליישם אמצעי לטעינה והפעלה מאובטחת של חלק מהאפליקציה שלהם ב-pVM, והמטען נבנה נגד glibc. אפליקציית אנדרואיד משתמשת ב-Bionic, תקשורת מצריכה פרוטוקול מותאם אישית מעל vsock, וניפוי באגים באמצעות adb הוא מאתגר.

Microdroid ממלא את הפערים הללו על ידי מתן תמונת מערכת הפעלה מהמדף שנועדה לדרוש את המאמץ המינימלי ממפתחים כדי להוריד חלק מהאפליקציה שלהם ל-pVM. קוד מקורי בנוי נגד Bionic, תקשורת מתרחשת באמצעות Binder, והוא מאפשר ייבוא ​​APEXs מאנדרואיד וחושף תת-קבוצה של ה-API של אנדרואיד, כמו מאגר מפתחות לפעולות קריפטוגרפיות עם מפתחות מגובי חומרה. בסך הכל, מפתחים צריכים למצוא ל-Microdroid סביבה מוכרת עם הכלים שהם הורגלו במערכת ההפעלה המלאה של אנדרואיד.

מאפיינים

Microdroid היא גרסה מופשטת של אנדרואיד עם כמה רכיבים נוספים ספציפיים ל-pVMs. Microdroid תומך:

• תת-קבוצה של ממשקי API של NDK (כל ממשקי ה-API עבור היישום של אנדרואיד של libc ו-Bionic מסופקים)
• תכונות ניפוי באגים, כגון adb, logcat, tombstone ו-gdb
• אתחול מאומת ו-SELinux מופעלים
• טעינה וביצוע של קובץ בינארי, יחד עם ספריות משותפות, מוטמע ב-APK
• Binder RPC על vsock והחלפת קבצים עם בדיקות תקינות מרומזות
• טעינת APEXs

Microdroid לא תומך ב:

• ממשקי API של Android Java בחבילות android.\*

• SystemServer ו-Zygote

• גרפיקה/ממשק משתמש

• HALs

ארכיטקטורת Microdroid

Microdroid דומה ל Cuttlefish בכך שלשניהם יש ארכיטקטורה הדומה לאנדרואיד הרגילה. Microdroid מורכב מתמונות המחיצה הבאות המקובצות יחד בתמונת דיסק מורכבת:

• bootloader - מאמת ומפעיל את הליבה.
• boot.img - מכיל את הקרנל ו-init ramdisk.
• vendor_boot.img - מכיל מודולי ליבה ספציפיים ל-VM, כגון virtio.
• super.img - מורכב ממחיצות לוגיות של מערכת וספק.
• vbmeta.img - מכיל מטא נתונים של אתחול מאומת.

תמונות המחיצה נשלחות ב-Virtualization APEX וארוזות בתמונת דיסק מורכבת על ידי VirtualizationService . בנוסף לתמונת הדיסק המרוכבת הראשית של מערכת ההפעלה, VirtualizationService אחראי ליצירת המחיצות האחרות הללו:

• payload - קבוצה של מחיצות מגובות על ידי APEX ו-APK של אנדרואיד
• instance - מחיצה מוצפנת עבור נתוני אתחול מאומתים בכל מופע, כגון מלח לכל מופע, מפתחות ציבוריים מהימנים של APEX ומונים לאחור

רצף אתחול

רצף האתחול של Microdroid מתרחש לאחר אתחול ההתקן . אתחול המכשיר נדון במסמך האדריכלות . איור 1 מציג את השלבים המתרחשים במהלך רצף האתחול של Microdroid:

להלן הסבר על השלבים:

1. טוען האתחול נטען לזיכרון על ידי crosvm ו-pvmfw מתחיל להפעיל. לפני הקפיצה ל-bootloader, pvmfw מבצע שתי משימות:

   • מאמת את טוען האתחול כדי לבדוק אם הוא ממקור מהימן (Google או OEM).
   • מבטיח שאותו טוען אתחול משמש באופן עקבי על פני מספר אתחולים של אותו pVM באמצעות שימוש בתמונת המופע. באופן ספציפי, ה-pVM מאוחל בתחילה עם תמונת מופע ריקה. pvmfw מאחסן את הזהות של טוען האתחול בתמונת המופע ומצפין אותה. אז, בפעם הבאה שה-pVM מאותחל עם אותה תמונת מופע, pvmfw מפענח את הזהות השמורה מתמונת המופע ומוודא שהיא זהה שנשמרה קודם לכן. אם הזהויות שונות, pvmfw מסרב לאתחל.

   לאחר מכן מטעין האתחול מאתחל את Microdroid.

2. טוען האתחול ניגש לדיסק המופע. בדומה ל-pvmfw, ל-bootloader יש כונן דיסקים של מופע עם מידע על תמונות מחיצות ששימשו במופע זה במהלך אתחולים קודמים, כולל המפתח הציבורי.

3. טוען האתחול מאמת את vbmeta ואת המחיצות המשורשרות, כגון boot ו- super , ואם מצליח, מפיק את סודות ה-pVM בשלב הבא. לאחר מכן, Microdroid מוסר את השליטה לקרנל.

4. מכיוון שמחיצת העל כבר אומתה על ידי טוען האתחול (שלב 3), הקרנל מעלה ללא תנאי את מחיצת העל. כמו באנדרואיד המלא, מחיצת העל מורכבת ממספר מחיצות לוגיות המותקנות על dm-verity. לאחר מכן השליטה מועברת לתהליך init , שמתחיל שירותים מקומיים שונים. הסקריפט init.rc דומה לזה של אנדרואיד מלא אך מותאם לצרכים של Microdroid.

5. תהליך init מתחיל את מנהל ה-Microdroid, אשר ניגש לתמונת המופע. שירות מנהל ה-Microdroid מפענח את התמונה באמצעות המפתח שהועבר מהשלב הקודם וקורא את המפתחות הציבוריים ואת מוני החזרה לאחור של ה-APK וה-APEX של הלקוח שה-pVM הזה סומך עליהם. מידע זה נמצא בשימוש מאוחר יותר על ידי zipfuse ו- apexd כאשר הם מעלים את ה-APK של הלקוח ו-APEXs המבוקש, בהתאמה.

6. שירות מנהל ה-Microdroid מתחיל apexd .

7. apexd מעלה את ה-APEXes ב- /apex/<name> ספריות. ההבדל היחיד בין האופן שבו Android ו-Microdroid mounta APEXs הוא שב-Microdroid, קבצי APEX מגיעים ממכשירי בלוק וירטואלי ( /dev/vdc1 , …), לא מקבצים רגילים ( /system/apex/*.apex ).

8. zipfuse היא מערכת הקבצים FUSE של Microdroid. zipfuse מעלה את ה-APK של הלקוח, שהוא בעצם קובץ Zip כמערכת קבצים. מתחת, קובץ ה-APK מועבר כהתקן בלוק וירטואלי על ידי ה-pVM עם dm-verity, זהה ל-APEX. ה-APK מכיל קובץ תצורה עם רשימה של APEXs שמפתח האפליקציה ביקש עבור מופע pVM זה. הרשימה משמשת את apexd בעת הפעלת APEXs.

9. זרימת האתחול חוזרת לשירות מנהל Microdroid. לאחר מכן, שירות המנהל מתקשר עם VirtualizationService של אנדרואיד באמצעות Binder RPC כך שהוא יכול לדווח על אירועים חשובים כמו קריסה או כיבוי, ולקבל בקשות כגון סיום ה-pVM. שירות המנהל קורא את המיקום של הקובץ הבינארי הראשי מקובץ התצורה של ה-APK ומבצע אותו.

החלפת קבצים (AuthFS)

מקובל שרכיבי אנדרואיד משתמשים בקבצים עבור קלט, פלט ומצב ומעבירים אותם כמתארי קבצים (סוג ParcelFileDescriptor ב-AIDL) עם גישה נשלטת על ידי ליבת אנדרואיד. AuthFS מאפשר פונקציונליות דומה להחלפת קבצים בין נקודות קצה שאינן אמון הדדית על פני גבולות pVM.

ביסודו של דבר, AuthFS היא מערכת קבצים מרוחקת עם בדיקות תקינות שקופות של פעולות גישה בודדות, בדומה ל- fs-verity . הבדיקות מאפשרות ל-frontend, כגון תוכנית לקריאת קבצים הפועלת ב-pVM, לזהות אם הקצה האחורי הלא מהימן, בדרך כלל אנדרואיד, התעסק בתוכן הקובץ.

כדי להחליף קבצים, הקצה האחורי ( fd\_server ) מופעל עם תצורה לכל קובץ המציינת אם הוא מיועד לקלט (לקריאה בלבד) או פלט (קריאה-כתיבה). לצורך קלט, ה-frontend אוכף שהתוכן תואם ל-hash ידוע, על גבי עץ Merkle לצורך אימות בגישה. עבור פלט, AuthFS מתחזק באופן פנימי עץ hash של התוכן כפי שנצפה מפעולות כתיבה ויכול לאכוף שלמות כאשר הנתונים נקראים בחזרה.

התחבורה הבסיסית מבוססת כרגע על Binder RPC, אולם זה עשוי להשתנות בעתיד כדי לייעל את הביצועים.

ניהול מפתח

מכשירי pVM מסופקים עם מפתח איטום יציב המתאים לנתונים קבועים מוגנים, ומפתח אישור המתאים להפקת חתימות המופקות באופן אימות על ידי ה-pVM.

קלסר RPC

רוב הממשקים של אנדרואיד מתבטאים ב- AIDL , אשר בנוי על גבי מנהל ההתקן של ליבת Binder Linux. כדי לתמוך בממשקים בין pVMs, פרוטוקול Binder נכתב מחדש כך שיעבוד על שקעים, vsock במקרה של pVMs. הפעלה על שקעים מאפשרת להשתמש בממשקי ה-AIDL הקיימים של אנדרואיד בסביבה חדשה זו.

כדי להגדיר את החיבור, נקודת קצה אחת, כגון pVM payload, יוצרת אובייקט RpcServer , רושם אובייקט שורש ומתחיל להאזין לחיבורים חדשים. לקוחות יכולים להתחבר לשרת זה באמצעות אובייקט RpcSession , לקבל את אובייקט Binder ולהשתמש בו בדיוק כמו שמשתמש באובייקט Binder עם מנהל ההתקן של ליבת Binder.