امنیت

«چارچوب مجازی‌سازی Android» (AVF) برای جلوگیری از اجرای بار مفید اختیاری در pVM از رویکرد امنیتی لایه‌ای استفاده می‌کند که در آن هر لایه اجرای بیشتری اضافه می‌کند. در زیر فهرستی از لایه‌های امنیتی AVF آمده است:

  • Android تضمین می‌کند که فقط برنامه‌هایی که اجازه‌های pVM دارند مجاز به ایجاد یا بازرسی pVM هستند.

  • بارکننده – بارکننده تضمین می‌کند که فقط تصاویر pVM امضاشده توسط Google یا فروشندگان دستگاه مجاز به راه‌اندازی باشند و از رویه راه‌اندازی تأییدشده Android پیروی می‌کند. این معماری به این معنی است که برنامه‌هایی که pVM اجرا می‌کنند نمی‌توانند هسته‌های خودشان را بسته‌بندی کنند.

  • pVM دفاعی عمیق ارائه می‌دهد، مثلاً با SELinux، برای داربارهایی که در pVM اجرا می‌شوند. دفاع در عمق، نگاشت داده‌ها را به‌عنوان قابل‌اجرا (neverallow execmem) غیرمجاز می‌کند و تضمین می‌کند که W^X برای همه انواع فایل‌ها برقرار است.

مدل امنیتی

محرمانگی، یکپارچگی، و دردسترس بودن (مثلث امنیت اطلاعات) مدلی را تشکیل می‌دهند که برای هدایت خط‌مشی‌های امنیت اطلاعات طراحی شده است:

  • محرمانگی مجموعه‌ای از قوانین است که دسترسی به اطلاعات را محدود می‌کند.
  • تمامیت به این معنا است که اطلاعات قابل‌اعتماد و دقیق باشد.
  • دردسترس بودن تضمینی برای دسترسی مطمئن به اطلاعات توسط نهادهای مجاز است.

محرمانگی و تمامیت

محرمانگی از ویژگی‌های جداسازی حافظه که توسط ابرناظر pKVM اعمال می‌شود ناشی می‌شود. pKVM مالکیت حافظه صفحه‌های حافظه فیزیکی فردی و هرگونه درخواست از مالکان برای هم‌رسانی صفحه‌ها را ردیابی می‌کند. pKVM تضمین می‌کند که فقط pVMهای واجدشرایط (میزبان و مهمان) صفحه داده‌شده را در جدول‌های صفحه مرحله ۲ که توسط ابرناظر کنترل می‌شوند نگاشت کنند. این معماری تضمین می‌کند که محتوای حافظه متعلق به pVM خصوصی باقی می‌ماند، مگر اینکه مالک صریحاً آن را با pVM دیگری هم‌رسانی کند.

محدودیت‌های حفظ محرمانگی به هر نهادی در سیستم که ازطرف pVM به حافظه دسترسی دارد نیز تعمیم داده می‌شود، یعنی دستگاه‌های با قابلیت DMA و سرویس‌هایی که در لایه‌های دارای امتیاز بیشتر اجرا می‌شوند. فروشندگان «سیستم روی تراشه» (SoC) باید مجموعه جدیدی از الزامات را برآورده کنند تا بتوانند از pKVM پشتیبانی کنند. درغیراین‌صورت، نمی‌توان محرمانگی را ارائه داد.

تمامیت برای داده‌های موجود در حافظه و محاسبات اعمال می‌شود. pVM نمی‌تواند:

  • بدون رضایت حافظه یکدیگر را تغییر دهند.
  • بر وضعیت واحد پردازش مرکزی یکدیگر تأثیر می‌گذارند.

این الزامات توسط ناظر ماشین مجازی اعمال می‌شود. بااین‌حال، مشکلات مربوط به تمامیت داده‌ها در فضای ذخیره‌سازی داده‌های مجازی نیز زمانی به‌وجود می‌آید که باید از راه‌حل‌های دیگری مثل dm-verity یا AuthFS استفاده شود.

این اصول با جداسازی پردازش ارائه‌شده توسط Linux تفاوتی ندارد که در آن دسترسی به صفحه‌های حافظه با جدول‌های صفحه مرحله ۱ کنترل می‌شود و هسته بین پردازش‌ها تعویض بافت انجام می‌دهد. بااین‌حال، بخش EL2 از pKVM که این ویژگی‌ها را اعمال می‌کند، در مقایسه با کل هسته Linux، سه مرتبه بزرگی سطح حمله کمتری دارد (تقریباً ۱۰ هزار در مقابل ۲۰ میلیون خط کد) و بنابراین اطمینان قوی‌تری برای موارد استفاده‌ای ارائه می‌دهد که برای تکیه بر جداسازی پردازش بسیار حساس هستند.

‫pKVM به‌دلیل اندازه خود برای درستی‌سنجی رسمی مناسب است. ما به‌طور فعال از پژوهش‌های دانشگاهی که هدفشان اثبات رسمی این ویژگی‌ها در باینری pKVM واقعی است حمایت می‌کنیم.

بقیه این صفحه به تضمین‌های محرمانگی و تمامیت که هر جزء در اطراف pKVM ارائه می‌دهد می‌پردازد.

Hypervisor

‫pKVM یک سرپرست ماشین مجازی مبتنی بر KVM است که pVM و Android را در محیط‌های اجرای متقابلاً غیرقابل‌اعتماد جدا می‌کند. این ویژگی‌ها درصورت به‌خطر افتادن هر pVM، ازجمله میزبان، حفظ می‌شوند. فراسرپرست‌های جایگزینی که با AVF مطابقت دارند باید ویژگی‌های مشابهی ارائه دهند.

  • ماشین مجازی صفحه‌ای متعلق به نهادی دیگر، مانند ماشین مجازی یا سرپرست، را نمی‌تواند ببیند، مگر اینکه مالک صفحه آن را صریحاً هم‌رسانی کرده باشد. این قانون شامل pVM میزبان می‌شود و هم برای دسترسی‌های CPU و هم DMA اعمال می‌شود.

  • قبل‌از اینکه صفحه‌ای که توسط pVM استفاده می‌شود به میزبان برگردانده شود، مثلاً وقتی pVM ازبین می‌رود، پاک می‌شود.

  • حافظه همه pVMها و میان‌افزار pVM از یک راه‌اندازی دستگاه قبل‌از اجرای راه‌انداز سیستم‌عامل در راه‌اندازی دستگاه بعدی پاک می‌شود.

  • وقتی اشکال‌زدای سخت‌افزاری، مثل SJTAG، متصل باشد، pVM نمی‌تواند به کلیدهای قبلاً ضرب‌شده‌اش دسترسی پیدا کند.

  • اگر سفت‌افزار pVM نتواند تصویر اولیه را درستی‌سنجی کند، راه‌اندازی نمی‌شود.

  • اگر تمامیت instance.img به‌خطر بیفتد، سفت‌افزار pVM راه‌اندازی نمی‌شود.

  • زنجیره گواهی DICE و «شناسه‌های دستگاه ترکیبی» (CDI) ارائه‌شده به نمونه pVM را فقط آن نمونه خاص می‌تواند استخراج کند.

سیستم عامل مهمان

Microdroid نمونه‌ای از سیستم‌عاملی است که در pVM اجرا می‌شود. Microdroid از یک بوت‌لودر مبتنی بر U-boot، GKI، و زیرمجموعه‌ای از فضای کاربری Android، و یک راه‌انداز بار داده تشکیل شده است. این ویژگی‌ها درصورت به‌خطر افتادن هر pVM، ازجمله میزبان، حفظ می‌شوند. سیستم‌عامل‌های جایگزینی که در pVM اجرا می‌شوند باید ویژگی‌های مشابهی ارائه دهند.

  • اگر boot.img،‏ super.img،‏ vbmeta.img، یا vbmeta\_system.img درستی‌سنجی نشود، Microdroid راه‌اندازی نخواهد شد.

  • اگر درستی‌سنجی APK ناموفق باشد، Microdroid راه‌اندازی نمی‌شود.

  • حتی اگر فایل APK به‌روزرسانی شده باشد، نمونه Microdroid یکسان راه‌اندازی نخواهد شد.

  • اگر هریک از APEXها درستی‌سنجی نشوند، Microdroid راه‌اندازی نخواهد شد.

  • اگر instance.img خارج از pVM مهمان تغییر کند، Microdroid راه‌اندازی نمی‌شود (یا با وضعیت اولیه پاک راه‌اندازی می‌شود).

  • Microdroid گواهی‌نامه زنجیره راه‌اندازی را ارائه می‌دهد.

  • هرگونه تغییر (بدون امضا) در تصاویر دیسک هم‌رسانی‌شده با ماشین مجازی مهمان باعث خطای ورودی/خروجی در سمت ماشین مجازی فیزیکی می‌شود.

  • زنجیره گواهی DICE و CDIهای ارائه‌شده به نمونه pVM فقط توسط همان نمونه خاص قابل‌استخراج است.

  • نوشتن در حجم ذخیره‌سازی رمزگذاری‌شده محرمانه است، اما در سطح جزئیات بلوک رمزگذاری، محافظت دربرابر بازگرداندن وجود ندارد. علاوه‌براین، دستکاری خارجی خودسرانه دیگر در یک بلوک داده باعث می‌شود آن بلوک به‌جای اینکه به‌طور صریح به‌عنوان خطای ورودی/خروجی شناسایی شود، برای Microdroid به‌صورت داده‌های نامعتبر ظاهر شود.

Android

این‌ها دارایی‌هایی هستند که Android به‌عنوان میزبان آن‌ها را حفظ می‌کند اما درصورت به‌خطر افتادن میزبان، این دارایی‌ها حفظ نمی‌شوند:

  • ماشین مجازی مهمان نمی‌تواند مستقیماً با ماشین‌های مجازی مهمان دیگر تعامل داشته باشد (مثلاً vsock اتصال برقرار کند).

  • فقط VirtualizationService در pVM میزبان می‌تواند کانال ارتباطی با pVM ایجاد کند.

  • فقط برنامه‌هایی که با کلید پلاتفرم امضا شده‌اند می‌توانند اجازه ایجاد، مالکیت، یا تعامل با pVM را درخواست کنند.

  • شناسه مورد استفاده در راه‌اندازی اتصالات vsock بین میزبان و pVM، که شناسه زمینه‌ای (CID) نامیده می‌شود، وقتی pVM میزبان درحال اجرا است دوباره استفاده نمی‌شود. برای مثال، نمی‌توانید pVM درحال اجرا را با pVM دیگری جایگزین کنید.

دردسترس بودن

در زمینه pVM، دردسترس بودن به میزبان اشاره دارد که منابع کافی را به مهمانان اختصاص می‌دهد تا مهمانان بتوانند وظایفی را که برای انجام آن‌ها طراحی شده‌اند انجام دهند.

مسئولیت‌های میزبان شامل زمان‌بندی CPUهای مجازی pVM است. KVM، برخلاف Hypervisorهای نوع ۱ مرسوم (مانند Xen)، تصمیم طراحی صریحی برای واگذاری زمان‌بندی حجم کاری به هسته میزبان می‌گیرد. با توجه به اندازه و پیچیدگی زمان‌بندهای امروزی، این تصمیم طراحی به‌طور قابل‌توجهی اندازه پایگاه محاسباتی مطمئن (TCB) را کاهش می‌دهد و میزبان را قادر می‌سازد تا تصمیمات زمان‌بندی آگاهانه‌تری برای بهینه‌سازی عملکرد بگیرد. بااین‌حال، یک میزبان مخرب می‌تواند انتخاب کند که هرگز مهمانی را زمان‌بندی نکند.

به‌همین ترتیب، pKVM نیز مدیریت وقفه فیزیکی را به هسته میزبان واگذار می‌کند تا پیچیدگی ابرناظر را کاهش دهد و میزبان را مسئول زمان‌بندی کند. تلاش می‌شود تا اطمینان حاصل شود که بازارسال کردن وقفه‌های مهمان فقط منجر به رد سرویس شود (وقفه‌های خیلی کم، خیلی زیاد، یا مسیردهی نادرست وقفه‌ها).

درنهایت، فرایند پایشگر ماشین مجازی میزبان (VMM) مسئول تخصیص حافظه و ارائه دستگاه‌های مجازی، مانند کارت شبکه است. «مدیر ماشین مجازی» مخرب می‌تواند منابع را از مهمان دریغ کند.

اگرچه pKVM دردسترس بودن را برای مهمانان فراهم نمی‌کند، اما طراحی آن از دردسترس بودن میزبان دربرابر مهمانان مخرب محافظت می‌کند زیرا میزبان همیشه می‌تواند مهمان را پیش‌دستی یا خاتمه دهد و منابع خود را پس بگیرد.

راه‌اندازی امن

داده‌ها به نمونه‌های pVM پیوند داده می‌شود و راه‌اندازی ایمن تضمین می‌کند که دسترسی به داده‌های نمونه کنترل‌پذیر باشد. اولین بوت یک نمونه آن را با تولید تصادفی یک نمک مخفی برای pVM و استخراج جزئیات، مانند کلیدهای عمومی و درهم‌سازی‌های درستی‌سنجی، از تصاویر بارگذاری‌شده آماده می‌کند. این اطلاعات برای درستی‌سنجی راه‌اندازی‌های بعدی نمونه pVM و اطمینان از اینکه اسرار نمونه فقط برای تصاویری که درستی‌سنجی را می‌گذرانند منتشر می‌شود استفاده می‌شود. این فرایند برای هر مرحله بارگیری در pVM رخ می‌دهد: میان‌افزار pVM،‏ pVM ABL،‏ Microdroid، و غیره.

DICE برای هر مرحله بار کردن یک جفت کلید گواهی ارائه می‌دهد که بخش عمومی آن در گواهی DICE برای آن مرحله تأیید شده است. این جفت کلید می‌تواند بین بوت‌ها تغییر کند، بنابراین یک راز آب‌بندی نیز استخراج می‌شود که برای نمونه ماشین مجازی در بوت‌های مجدد پایدار است و به همین دلیل برای محافظت از وضعیت ماندگار مناسب است. رمز پلمب برای ماشین مجازی بسیار ارزشمند است، بنابراین نباید مستقیماً استفاده شود. درعوض، کلیدهای آب‌بندی باید از رمز آب‌بندی مشتق شوند و رمز آب‌بندی باید در اسرع وقت ازبین برود.

هر مرحله یک شیء CBOR را که به‌صورت قطعی کدگذاری شده است به مرحله بعدی تحویل می‌دهد. این شیء حاوی اسرار و زنجیره گواهینامه DICE است که حاوی اطلاعات وضعیت انباشته‌شده است، مثلاً اینکه آخرین مرحله به‌طور ایمن بارگیری شده است یا نه.

دستگاه‌های باز

وقتی قفل دستگاه با fastboot oem unlock باز می‌شود، داده‌های کاربر پاک می‌شود. این فرایند از داده‌های کاربر دربرابر دسترسی غیرمجاز محافظت می‌کند. داده‌های خصوصی مربوط به pVM نیز هنگام باز شدن قفل دستگاه نامعتبر می‌شود.

پس‌از باز شدن قفل، مالک دستگاه می‌تواند آزادانه پارتیشن‌هایی را که معمولاً با راه‌اندازی درستی‌سنجی‌شده محافظت می‌شوند، ازجمله پارتیشن‌های حاوی pvmfw و پیاده‌سازی pKVM، مجدداً فلش کند. بنابراین، دستگاهی که قفل آن باز شده باشد برای حفظ مدل امنیتی pVM قابل‌اعتماد نیست.

طرف‌های راه دور می‌توانند این وضعیت بالقوه ناامن را با بررسی وضعیت راه‌اندازی درستی‌سنجی‌شده دستگاه در گواهی تصدیق کلید مشاهده کنند.