למה AVF?

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

מערכות הפעלה, בעזרת יחידות ניהול זיכרון חומרה (MMU), מספקות הפשטות המאפשרות לבודד תהליכים לא קשורים זה מזה. רק רכיבים שהם חלק מה-TCB רשאים לתכנת ישירות את ה-MMU האלה.

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

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

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

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

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

בנוסף, ממשקי ה-API המשמשים מחוץ למערכת ההפעלה אנדרואיד מפוצלים ומגבילים את היכולת שלנו לפרוס מקרי שימוש בסולם אנדרואיד, כולל יסודות כמו Keymint ו-Gatekeeper.

כדי לטפל במגבלות אלו ולאפשר לאנדרואיד לספק בסיס חזק למקרי השימוש בדור הבא, אנדרואיד 13 מציגה וירטואליזציה מאובטחת כמסגרת הוירטואליזציה של אנדרואיד (AVF).

המטרה העיקרית של AVF היא לספק סביבת ביצוע מאובטחת ופרטית למקרי שימוש של הדור הבא.