אבטחה

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

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

  • תוכנת אתחול – תוכנת האתחול מוודאת שרק תמונות pVM שנחתמו על ידי Google או ספקים של מכשירים יורשו לבצע הפעלה, והיא פועלת בהתאם לתהליך האתחול המאומת של Android. לפי הארכיטקטורה הזו, אפליקציות שמפעילות מכונות pVM לא יכולות לקבץ את הליבה שלהן.

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

מודל אבטחה

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

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

סודיות ויושרה

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

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

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

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

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

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

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

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

Hypervisor

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

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

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

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

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

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

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

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

מערכת הפעלה לאורחים

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

  • המיקרו-דרום לא יופעל אם לא ניתן לאמת את boot.img, את super.img, את vbmeta.img או את vbmeta\_system.img.

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

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

  • ה-Microdroid לא יופעל אם אחד מה-APEX ייכשל באימות.

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

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

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

  • רק המכונה הספציפית יכולה ליצור את שרשרת אישורי DICE ומזהי ה-CDI שסופקו למכונה ה-pVM.

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

Android

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

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

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

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

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

זמינות

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

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

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

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

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

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

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

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

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

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

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

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

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