אבטחה

כדי למנוע הפעלה של עומסי עבודה שרירותיים בתוך pVM, Android Virtualization Framework‏ (AVF) משתמש בגישה של אבטחה בשכבות, שבה כל שכבה מוסיפה אכיפה נוספת. זו רשימה של שכבות האבטחה של AVF:

• מערכת Android מוודאת שרק אפליקציות עם הרשאות ל-pVM יכולות ליצור או לבדוק מכונות pVM.

• Bootloader – ה-bootloader מוודא שרק קובצי אימג' של pVM שנחתמו על ידי Google או על ידי ספקי המכשירים מורשים להפעיל את המכשיר, ופועל בהתאם לפרוצדורה של Android Verified Boot. הארכיטקטורה הזו מחייבת שאפליקציות שפועלות ב-pVM לא יכולות לקבץ לעצמן ליבות.

• pVM מספק הגנה לעומס עבודה (payload) שפועל ב-pVM, למשל באמצעות SELinux. הגנה לעומק אוסרת על מיפוי נתונים כקובץ הפעלה (neverallow execmem) ומוודאת שW^X תקף לכל סוגי הקבצים.

מודל אבטחה

הסודיות, התקינות והזמינות (משולש ה-CIA) הם מודל שמיועד להנחות את כללי המדיניות לאבטחת מידע:

• סודיות היא קבוצת כללים שמגבילה את הגישה למידע.
• תקינות היא הביטחון שהמידע מהימן ומדויק.
• זמינות היא הבטחה לגישה מהימנה למידע על ידי ישויות מורשות.

סודיות ותקינות

הסודיות נובעת ממאפייני בידוד הזיכרון שמופעלים על ידי hypervisor של pKVM. ‏pKVM עוקב אחרי בעלות הזיכרון של דפי זיכרון פיזיים ספציפיים וכל בקשה מהבעלים לשיתוף דפים. ‏pKVM מוודא שרק למכונות וירטואליות מורשות (מארחים ומארחים אורחים) יש את המיפוי של הדף הנתון בטבלאות הדפים שלהן בשלב 2, שנמצאות בשליטת hypervisor. הארכיטקטורה הזו מבטיחה שתוכן הזיכרון שבבעלות של pVM יישאר פרטי, אלא אם הבעלים ישתף אותו באופן מפורש עם pVM אחר.

ההגבלות לשמירה על הסודיות חלות גם על כל ישות במערכת שמבצעת גישה לזיכרון מטעם מכונות וירטואליות פרטיות (pVM), כלומר מכשירי DMA ושירותים שפועלים בשכבות עם הרשאות גבוהות יותר. ספקי מעבדים (SoC) צריכים לעמוד בדרישות חדשות כדי שיוכלו לתמוך ב-pKVM. אם לא, לא ניתן לספק סודיות.

התקינות חלה על נתונים בזיכרון ועל חישוב. מכונות pVM לא יכולות:

• לשנות את הזכרונות של האחרים ללא הסכמה.
• להשפיע על מצב ה-CPU של כל אחת מהן.

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

העקרונות האלה לא שונים מהבידוד של תהליכים שמציע Linux, שבו הגישה לדפי הזיכרון נשלטת באמצעות טבלאות דפים של שלב 1 והמעברים של ההקשר (context-switches) בליבה בין תהליכים. עם זאת, בחלק EL2 של pKVM, שמאכסה את המאפיינים האלה, יש שטח התקפה קטן פי שלושה בהשוואה לליבת Linux כולה (כ-10,000 שורות קוד לעומת 20 מיליון שורות קוד), ולכן הוא מספק ביטחון חזק יותר בתרחישי שימוש שהם רגישים מדי כדי להסתמך על בידוד תהליכים.

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

בהמשך הדף נסביר על ההתחייבויות לסודיות ולתקינות שכל רכיב מסביב ל-pKVM מספק.

hypervisor

pKVM הוא hypervisor מבוסס-KVM שמבודד מכונות pVM ו-Android בסביבות מחשוב לא מהימנות זו לזו. המאפיינים האלה תקפים במקרה של פגיעה בכל מכונה וירטואלית, כולל המארח. למכונות וירטואליות חלופיות שתואמות ל-AVF צריכים להיות מאפיינים דומים.

• ל-pVM אין גישה לדף ששייך לישות אחרת, כמו pVM או hypervisor, אלא אם הבעלים של הדף משתף אותו באופן מפורש. הכלל הזה כולל את ה-pVM המארח חל גם על גישה ל-CPU וגם על גישה ל-DMA.

• לפני שדף שמשמש את ה-pVM מוחזר למארח, למשל כשה-pVM נהרס, הוא נמחק.

• הזיכרון של כל ה-pVM ותוכנת הקושחה של ה-pVM מאתחול אחד של המכשיר נמחקים לפני שתוכנת האתחול של מערכת ההפעלה פועלת באתחול הבא של המכשיר.

• כשמחוברת תכונת ניפוי באגים בחומרה, כמו SJTAG, ל-pVM אין גישה למפתחות שיצר בעבר.

• קושחת ה-pVM לא תופעל אם היא לא תוכל לאמת את התמונה הראשונית.

• קושחת ה-pVM לא תאתחל אם תהיה פגיעה בתקינות של instance.img.

• רק המכונה הספציפית יכולה להפיק את רשת האישורים של DICE ואת מזהי המכשירים המשולבים (CDIs) שסופקו למכונה הווירטואלית.

מערכת ההפעלה של האורח

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

• Microdroid לא יתעדכן אם לא ניתן לאמת את boot.img,‏ super.img,‏ vbmeta.img או vbmeta\_system.img.

• אם אימות ה-APK נכשל, Microdroid לא יופעל.

• אותה מכונה של Microdroid לא תופעל גם אם ה-APK עודכן.

• Microdroid לא יופעל אם אחת מ-APEXes נכשלת באימות.

• Microdroid לא יפעל (או יפעל במצב ראשוני נקי) אם הקובץ instance.img ישתנה מחוץ ל-pVM של האורח.

• Microdroid מספק אימות לרשת האתחול.

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

• רק המכונה הספציפית יכולה להפיק את שרשרת האישורים וה-CDIs של DICE שסופקו למכונה הווירטואלית.

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

Android

אלה מאפיינים שנשמרים על ידי Android בתור המארח, אבל לא תקפים במקרה של פריצה למארח:

• מכונה וירטואלית אורחת לא יכולה לקיים אינטראקציה ישירה עם מכונות וירטואליות אורחות אחרות (למשל, ליצור vsock חיבור).

• רק ה-VirtualizationService ב-pVM המארח יכול ליצור ערוץ תקשורת ל-pVM.

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

• המזהה, שנקרא מזהה הקשר (CID), משמש להגדרת חיבורי vsock בין המארח ל-pVM, ולא נעשה בו שימוש חוזר כש-pVM המארח פועל. לדוגמה, אי אפשר להחליף מכונה וירטואלית שפועלת ב-pVM אחרת.

זמינות

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

בין האחריות של המארח נכללת תזמון של מעבדי ה-CPU הווירטואליים של ה-pVM. בניגוד למערכות ה-hypervisor הרגילות מסוג 1 (כמו Xen), ב-KVM הוחלט במפורש להעניק לליבת המארח את הסמכות התזמון של עומסי העבודה. בגלל הגודל והמורכבות של מתזמן המשימות של היום, החלטת התכנון הזו מפחיתה באופן משמעותי את גודל בסיס המחשוב המהימן (TCB) ומאפשרת למארח לקבל החלטות מתוכננות יותר לגבי תזמון כדי לבצע אופטימיזציה של הביצועים. עם זאת, מארח זדוני יכול לבחור אף פעם לא לתזמן אורחים.

באופן דומה, גם ב-pKVM הטיפול בהפרעות פיזיות מופקד על הליבה של המארח כדי לצמצם את המורכבות של hypervisor ולהשאיר את המארח אחראי לתזמון. אנחנו משקיעים מאמצים כדי לוודא שההעברה של השיבושים של האורחים תגרום רק להתקפת מניעת שירות (DDoS) (מעט מדי שיבושים, יותר מדי שיבושים או שיבושים שהועברו ליעדים שגויים).

לבסוף, תהליך המפקח על המכונות הווירטואליות (VMM) של המארח אחראי להקצאת זיכרון ולמתן מכשירים וירטואליים, כמו כרטיס רשת. VMM זדוני יכול להסתיר משאבים מהאורח.

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

הפעלה מאובטחת

הנתונים קשורים למכונות של pVM, והפעלה מאובטחת מבטיחה שאפשר לשלוט בגישה לנתונים של המכונה. האתחול הראשון של המכונה מקצה אותה על ידי יצירת מלח סודי באופן אקראי ל-pVM וחילוץ פרטים, כמו מפתחות ציבוריים לאימות וגיבוב, מהתמונות שהועלו. המידע הזה משמש לאימות אתחולים נוספים של המכונה הווירטואלית (pVM) ולוודא שהסודות של המכונה ייחשפו רק לאימג'ים שעוברים את האימות. התהליך הזה מתרחש בכל שלב טעינה ב-pVM: קושחת pVM, ‏pVM ABL, ‏Microdroid וכו'.

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

כל שלב מעביר לשלב הבא אובייקט CBOR עם קידוד דטרמיניסטי. האובייקט הזה מכיל סודות ורשת האישורים של DICE, שמכילה מידע מצטבר על הסטטוס, למשל אם השלב האחרון נטען בצורה מאובטחת.

מכשירים נעולים

כשמנעילים את המכשיר באמצעות fastboot oem unlock, נתוני המשתמש נמחקים. התהליך הזה מגן על נתוני המשתמשים מפני גישה לא מורשית. גם נתונים פרטיים של מכונה וירטואלית פרטית (pVM) לא תקפים כשהמכשיר נפתח.

אחרי ביטול הנעילה, הבעלים של המכשיר יכולים לבצע מחיקת נתונים (flash) מחדש של מחיצות שבדרך כלל מוגנות באמצעות אתחול מאומת, כולל המחיצות שמכילות את ההטמעה של pKVM. לכן, לא ניתן יהיה לסמוך על pKVM במכשיר לא נעול כדי לשמור על מודל האבטחה.

צדדים מרוחקים יכולים לזהות את המצב הלא מאובטח הזה על ידי בדיקת מצב ההפעלה המאומתת של המכשיר באישור אימות המפתח.