امنیت

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

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

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

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

مدل امنیتی

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

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

محرمانگی و یکپارچگی

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

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

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

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

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

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

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

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

هایپروایزر

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

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

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

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

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

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

• اگر یکپارچگی فایل instance.img به خطر بیفتد، فریمور pVM بوت نمی‌شود.

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

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

میکرودروید نمونه‌ای از یک سیستم عامل است که درون یک pVM اجرا می‌شود. میکرودروید شامل یک بوت لودر مبتنی بر U-boot، GKI، و زیرمجموعه‌ای از فضای کاربری اندروید و یک لانچر payload است. این ویژگی‌ها در صورت بروز هرگونه مشکل در هر pVM، از جمله میزبان، پابرجا می‌مانند. سیستم عامل‌های جایگزین که در یک pVM اجرا می‌شوند، باید ویژگی‌های مشابهی را ارائه دهند.

• اگر boot.img ، super.img ، vbmeta.img یا vbmeta\_system.img تأیید نشوند، میکرودروید بوت نخواهد شد.

• اگر تأیید APK با شکست مواجه شود، میکرودروید بوت نخواهد شد.

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

• اگر هر یک از APEXها در تأیید ناموفق باشند، میکرودروید بوت نخواهد شد.

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

• میکرودروید گواهی زنجیره بوت را ارائه می‌دهد.

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

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

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

اندروید

اینها ویژگی‌هایی هستند که توسط اندروید به عنوان میزبان نگهداری می‌شوند، اما در صورت به خطر افتادن میزبان، صادق نیستند:

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

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

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

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

در دسترس بودن

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

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

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

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

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

بوت امن

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

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

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

دستگاه‌های قفل‌گشایی‌شده

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

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

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