امنیت

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

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

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

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

مدل امنیتی

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

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

رازداری و صداقت

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

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

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

• حافظه یکدیگر را بدون رضایت اصلاح کنید.
• بر وضعیت CPU یکدیگر تأثیر بگذارند.

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

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

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

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

هایپروایزر

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

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

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

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

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

• سیستم عامل pVM اگر نتواند تصویر اولیه را تأیید کند، بوت نمی شود.

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

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

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

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

• اگر boot.img ، super.img ، vbmeta.img ، یا vbmeta\_system.img قابل تأیید نباشد، Microdroid بوت نمی‌شود.

• در صورت عدم موفقیت در تأیید APK، Microdroid بوت نمی‌شود.

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

• اگر هر یک از APEX ها در تأیید صحت نشوند، Microdroid بوت نمی شود.

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

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

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

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

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

اندروید

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

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

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

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

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

در دسترس بودن

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

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

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

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

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

بوت ایمن

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

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

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

دستگاه های آنلاک شده

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

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

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