Arsitektur AVF

Android menyediakan referensi implementasi semua komponen yang diperlukan untuk mengimplementasikan Kerangka Virtualisasi Android. Saat ini implementasi ini terbatas pada ARM64. Halaman ini menjelaskan arsitektur kerangka kerja.

Latar belakang

Arsitektur Arm mengizinkan hingga empat tingkat pengecualian, dengan pengecualian tingkat 0 (EL0) sebagai yang paling sedikit hak istimewanya, dan pengecualian tingkat 3 (EL3) yang paling banyak. Porsi terbesar basis kode Android (semua komponen ruang pengguna) berjalan pada EL0. Selebihnya yang biasa disebut "Android" adalah kernel Linux yang berjalan pada EL1.

Lapisan EL2 memungkinkan pengenalan hypervisor yang memungkinkan isolasi memori dan perangkat ke dalam pVM individual di EL1/EL0, dengan jaminan kerahasiaan dan integritas yang kuat.

hipervisor

Mesin virtual berbasis kernel yang dilindungi (pKVM) dibangun di atas hypervisor KVM Linux , yang telah diperluas dengan kemampuan untuk membatasi akses ke muatan yang berjalan di mesin virtual tamu yang ditandai 'dilindungi' pada saat pembuatan.

KVM/arm64 mendukung mode eksekusi yang berbeda tergantung pada ketersediaan fitur CPU tertentu, yaitu Virtualization Host Extensions (VHE) (ARMv8.1 dan yang lebih baru). Dalam salah satu mode tersebut, umumnya dikenal sebagai mode non-VHE, kode hypervisor dipisahkan dari image kernel saat boot dan diinstal pada EL2, sedangkan kernel itu sendiri berjalan pada EL1. Meskipun merupakan bagian dari basis kode Linux, komponen EL2 dari KVM adalah komponen kecil yang bertanggung jawab atas peralihan antara beberapa EL1, dan sepenuhnya dikendalikan oleh kernel host. Komponen hypervisor dikompilasi dengan Linux, tetapi berada di bagian memori khusus yang terpisah dari image vmlinux . pKVM memanfaatkan desain ini dengan memperluas kode hypervisor dengan fitur-fitur baru yang memungkinkannya membatasi kernel host Android dan ruang pengguna, serta membatasi akses host ke memori tamu dan hypervisor.

modul vendor pKVM

Modul vendor pKVM adalah modul khusus perangkat keras yang berisi fungsionalitas khusus perangkat, seperti driver unit manajemen memori input-output (IOMMU). Modul ini memungkinkan Anda mem-porting fitur keamanan yang memerlukan akses pengecualian level 2 (EL2) ke pKVM.

Untuk mempelajari cara menerapkan dan memuat modul vendor pKVM, lihat Mengimplementasikan modul vendor pKVM .

Prosedur booting

Gambar berikut menggambarkan prosedur boot pKVM:

1. Bootloader memasuki kernel generik di EL2.
2. Kernel generik mendeteksi bahwa ia berjalan di EL2 dan mencabut hak istimewanya ke EL1 sementara pKVM dan modul-modulnya terus berjalan di EL2. Selain itu, modul vendor pKVM dimuat saat ini.
3. Kernel generik melanjutkan boot secara normal, memuat semua driver perangkat yang diperlukan hingga mencapai ruang pengguna. Pada titik ini, pKVM sudah ada dan menangani tabel halaman tahap-2.

Prosedur boot mempercayai bootloader untuk menjaga integritas image kernel hanya selama boot awal. Ketika kernel dicabut haknya, kernel tersebut tidak lagi dianggap dipercaya oleh hypervisor, yang kemudian bertanggung jawab untuk melindungi dirinya sendiri bahkan jika kernel disusupi.

Memiliki kernel Android dan hypervisor dalam gambar biner yang sama memungkinkan antarmuka komunikasi yang sangat erat di antara keduanya. Kopling ketat ini menjamin pembaruan atomik pada kedua komponen, sehingga menghindari kebutuhan untuk menjaga antarmuka di antara keduanya tetap stabil, dan menawarkan banyak fleksibilitas tanpa mengorbankan pemeliharaan jangka panjang. Kopling ketat juga memungkinkan optimalisasi kinerja ketika kedua komponen dapat bekerja sama tanpa memengaruhi jaminan keamanan yang diberikan oleh hypervisor.

Selain itu, penerapan GKI di ekosistem Android secara otomatis memungkinkan hypervisor pKVM diterapkan ke perangkat Android dalam biner yang sama dengan kernel.

Perlindungan akses memori CPU

Arsitektur Arm menetapkan unit manajemen memori (MMU) yang dibagi menjadi dua tahap independen, keduanya dapat digunakan untuk mengimplementasikan terjemahan alamat dan kontrol akses ke berbagai bagian memori. MMU tahap 1 dikendalikan oleh EL1 dan memungkinkan terjemahan alamat tingkat pertama. MMU tahap 1 digunakan oleh Linux untuk mengelola ruang alamat virtual yang disediakan untuk setiap proses ruang pengguna dan ruang alamat virtualnya sendiri.

MMU tahap 2 dikendalikan oleh EL2 dan memungkinkan penerapan terjemahan alamat kedua pada alamat keluaran MMU tahap 1, menghasilkan alamat fisik (PA). Terjemahan tahap 2 dapat digunakan oleh hypervisor untuk mengontrol dan menerjemahkan akses memori dari semua VM tamu. Seperti yang ditunjukkan pada gambar 2, ketika kedua tahap penerjemahan diaktifkan, alamat keluaran tahap 1 disebut alamat fisik perantara (IPA). Catatan: Alamat virtual (VA) diterjemahkan ke dalam IPA dan kemudian ke PA.

Secara historis, KVM berjalan dengan terjemahan tahap 2 diaktifkan saat menjalankan tamu dan dengan tahap 2 dinonaktifkan saat menjalankan kernel Linux host. Arsitektur ini memungkinkan akses memori dari MMU tahap 1 host melewati MMU tahap 2, sehingga memungkinkan akses tidak terbatas dari host ke halaman memori tamu. Di sisi lain, pKVM mengaktifkan perlindungan tahap 2 bahkan dalam konteks host, dan menempatkan hypervisor yang bertugas melindungi halaman memori tamu, bukan host.

KVM memanfaatkan sepenuhnya terjemahan alamat pada tahap 2 untuk mengimplementasikan pemetaan IPA/PA yang kompleks bagi para tamu, yang menciptakan ilusi memori yang berdekatan bagi para tamu meskipun ada fragmentasi fisik. Namun, penggunaan MMU tahap 2 untuk host dibatasi hanya untuk kontrol akses saja. Host tahap 2 dipetakan identitasnya, memastikan bahwa memori yang berdekatan di ruang IPA host berdekatan di ruang PA. Arsitektur ini memungkinkan penggunaan pemetaan besar dalam tabel halaman dan akibatnya mengurangi tekanan pada buffer terjemahan lookaside (TLB). Karena pemetaan identitas dapat diindeks oleh PA, host tahap 2 juga digunakan untuk melacak kepemilikan halaman secara langsung di tabel halaman.

Perlindungan akses memori langsung (DMA).

Seperti dijelaskan sebelumnya, membuka peta halaman tamu dari host Linux di tabel halaman CPU adalah langkah yang diperlukan namun tidak cukup untuk melindungi memori tamu. pKVM juga perlu melindungi terhadap akses memori yang dilakukan oleh perangkat berkemampuan DMA di bawah kendali kernel host, dan kemungkinan serangan DMA yang diprakarsai oleh host jahat. Untuk mencegah perangkat tersebut mengakses memori tamu, pKVM memerlukan perangkat keras unit manajemen memori input-output (IOMMU) untuk setiap perangkat berkemampuan DMA dalam sistem, seperti yang ditunjukkan pada gambar 3.

Minimal, perangkat keras IOMMU menyediakan sarana untuk memberikan dan mencabut akses baca/tulis perangkat ke memori fisik pada tingkat granularitas halaman. Namun, perangkat keras IOMMU ini membatasi penggunaan perangkat di pVM karena perangkat tersebut mengasumsikan tahap 2 yang dipetakan identitas.

Untuk memastikan isolasi antar mesin virtual, transaksi memori yang dihasilkan atas nama entitas yang berbeda harus dapat dibedakan oleh IOMMU sehingga kumpulan tabel halaman yang sesuai dapat digunakan untuk penerjemahan.

Selain itu, mengurangi jumlah kode khusus SoC di EL2 merupakan strategi utama untuk mengurangi basis komputasi tepercaya (TCB) pKVM secara keseluruhan dan bertentangan dengan penyertaan driver IOMMU di hypervisor. Untuk memitigasi masalah ini, host di EL1 bertanggung jawab atas tugas manajemen tambahan IOMMU, seperti manajemen daya, inisialisasi dan, jika diperlukan, penanganan interupsi.

Namun, menempatkan host dalam kendali status perangkat menempatkan persyaratan tambahan pada antarmuka pemrograman perangkat keras IOMMU untuk memastikan bahwa pemeriksaan izin tidak dapat dilewati dengan cara lain, misalnya, setelah pengaturan ulang perangkat.

IOMMU standar dan didukung dengan baik untuk perangkat Arm yang memungkinkan isolasi dan penugasan langsung adalah arsitektur Arm System Memory Management Unit (SMMU). Arsitektur ini adalah solusi referensi yang direkomendasikan.

Kepemilikan memori

Pada saat boot, semua memori non-hypervisor diasumsikan dimiliki oleh host, dan dilacak oleh hypervisor. Ketika pVM muncul, host menyumbangkan halaman memori agar dapat melakukan booting dan hypervisor mengalihkan kepemilikan halaman tersebut dari host ke pVM. Dengan demikian, hypervisor menerapkan pembatasan kontrol akses pada tabel halaman tahap 2 host untuk mencegahnya mengakses halaman lagi, sehingga memberikan kerahasiaan kepada tamu.

Komunikasi antara tuan rumah dan tamu dimungkinkan melalui pembagian memori yang terkontrol di antara mereka. Para tamu diizinkan untuk membagikan kembali beberapa halaman mereka dengan host menggunakan hypercall, yang menginstruksikan hypervisor untuk memetakan ulang halaman-halaman tersebut di tabel halaman tahap 2 host. Demikian pula, komunikasi host dengan TrustZone dimungkinkan melalui operasi berbagi memori dan/atau peminjaman, yang semuanya dipantau dan dikontrol secara ketat oleh pKVM menggunakan spesifikasi Firmware Framework for Arm (FF-A) .

Karena kebutuhan memori pVM dapat berubah seiring waktu, hypercall disediakan yang memungkinkan kepemilikan halaman tertentu milik pemanggil dilepaskan kembali ke host. Dalam praktiknya hypercall ini digunakan dengan protokol balon virtio untuk memungkinkan VMM meminta kembali memori dari pVM, dan agar pVM memberi tahu VMM tentang halaman yang dilepaskan, dengan cara yang terkendali.

Hypervisor bertanggung jawab untuk melacak kepemilikan semua halaman memori dalam sistem dan apakah halaman tersebut dibagikan atau dipinjamkan ke entitas lain. Sebagian besar pelacakan keadaan ini dilakukan dengan menggunakan metadata yang dilampirkan pada tabel halaman tahap 2 host dan tamu, menggunakan bit yang dicadangkan dalam entri tabel halaman (PTE) yang, seperti namanya, dicadangkan untuk penggunaan perangkat lunak.

Host harus memastikan bahwa ia tidak mencoba mengakses halaman yang dibuat tidak dapat diakses oleh hypervisor. Akses host ilegal menyebabkan pengecualian sinkron dimasukkan ke dalam host oleh hypervisor, yang dapat mengakibatkan tugas ruang pengguna yang bertanggung jawab menerima sinyal SEGV, atau kernel host mogok. Untuk mencegah akses yang tidak disengaja, halaman yang didonasikan kepada tamu dibuat tidak memenuhi syarat untuk ditukar atau digabungkan oleh kernel host.

Penanganan interupsi dan pengatur waktu

Interupsi adalah bagian penting dari cara tamu berinteraksi dengan perangkat dan komunikasi antar CPU, di mana interupsi antarprosesor (IPI) adalah mekanisme komunikasi utama. Model KVM adalah mendelegasikan semua manajemen interupsi virtual ke host di EL1, yang untuk tujuan tersebut berperilaku sebagai bagian hypervisor yang tidak dipercaya.

pKVM menawarkan emulasi Generic Interrupt Controller versi 3 (GICv3) lengkap berdasarkan kode KVM yang ada. Timer dan IPI ditangani sebagai bagian dari kode emulasi yang tidak tepercaya ini.

dukungan GICv3

Antarmuka antara EL1 dan EL2 harus memastikan bahwa status interupsi penuh dapat dilihat oleh host EL1, termasuk salinan register hypervisor yang terkait dengan interupsi. Visibilitas ini biasanya dicapai dengan menggunakan wilayah memori bersama, satu per CPU virtual (vCPU).

Kode dukungan runtime register sistem dapat disederhanakan untuk hanya mendukung perangkap register Software Generated Interrupt Register (SGIR) dan Deactivate Interrupt Register (DIR). Arsitekturnya mengamanatkan bahwa register ini selalu menjebak ke EL2, sedangkan jebakan lainnya sejauh ini hanya berguna untuk mengurangi kesalahan. Segala sesuatu yang lain ditangani di perangkat keras.

Di sisi MMIO, semuanya ditiru di EL1, menggunakan kembali semua infrastruktur yang ada di KVM. Terakhir, Wait for Interrupt (WFI) selalu diteruskan ke EL1, karena ini adalah salah satu penjadwalan primitif dasar yang digunakan KVM.

Dukungan pengatur waktu

Nilai komparator untuk pengatur waktu virtual harus diekspos ke EL1 pada setiap WFI yang menjebak sehingga EL1 dapat memasukkan interupsi pengatur waktu saat vCPU diblokir. Pengatur waktu fisik sepenuhnya ditiru, dan semua jebakan diteruskan ke EL1.

penanganan MMIO

Untuk berkomunikasi dengan monitor mesin virtual (VMM) dan melakukan emulasi GIC, perangkap MMIO harus diteruskan kembali ke host di EL1 untuk triase lebih lanjut. pKVM memerlukan hal berikut:

• IPA dan ukuran akses
• Data jika ada penulisan
• Endianness CPU pada titik terjebak

Selain itu, jebakan dengan register tujuan umum (GPR) sebagai sumber/tujuan diteruskan menggunakan register semu transfer abstrak.

Antarmuka tamu

Seorang tamu dapat berkomunikasi dengan tamu yang dilindungi menggunakan kombinasi hypercall dan akses memori ke wilayah yang terperangkap. Hypercall diekspos sesuai dengan standar SMCCC , dengan rentang yang dicadangkan untuk alokasi vendor oleh KVM. Hypercall berikut ini sangat penting bagi tamu pKVM.

Hypercall umum

• PSCI menyediakan mekanisme standar bagi tamu untuk mengontrol siklus hidup vCPU termasuk online, offline, dan shutdown sistem.
• TRNG menyediakan mekanisme standar bagi tamu untuk meminta entropi dari pKVM yang meneruskan panggilan ke EL3. Mekanisme ini sangat berguna ketika host tidak dapat dipercaya untuk memvirtualisasikan generator nomor acak (RNG) perangkat keras.

hypercall pKVM

• Berbagi memori dengan tuan rumah. Semua memori tamu pada awalnya tidak dapat diakses oleh host, namun akses host diperlukan untuk komunikasi memori bersama dan untuk perangkat paravirtualisasi yang mengandalkan buffer bersama. Hypercall untuk berbagi dan membatalkan berbagi halaman dengan host memungkinkan tamu memutuskan dengan tepat bagian memori mana yang dapat diakses oleh seluruh Android tanpa perlu jabat tangan.
• Pelepasan memori kepada tuan rumah. Semua memori tamu biasanya menjadi milik tamu tersebut sampai dihancurkan. Keadaan ini mungkin tidak memadai untuk VM yang berumur panjang dengan kebutuhan memori yang bervariasi dari waktu ke waktu. relinquish hypercall memungkinkan tamu untuk secara eksplisit mentransfer kepemilikan halaman kembali ke host tanpa memerlukan penghentian tamu.
• Akses memori terperangkap ke host. Secara tradisional, jika tamu KVM mengakses alamat yang tidak sesuai dengan wilayah memori yang valid, maka thread vCPU keluar ke host dan akses tersebut biasanya digunakan untuk MMIO dan ditiru oleh VMM di ruang pengguna. Untuk memfasilitasi penanganan ini, pKVM diharuskan untuk mengiklankan rincian tentang instruksi kesalahan seperti alamatnya, parameter register dan kemungkinan isinya kembali ke host, yang secara tidak sengaja dapat mengekspos data sensitif dari tamu yang dilindungi jika jebakan tidak diantisipasi. pKVM memecahkan masalah ini dengan memperlakukan kesalahan ini sebagai kesalahan fatal kecuali tamu sebelumnya telah mengeluarkan hypercall untuk mengidentifikasi rentang IPA yang salah sebagai rentang akses yang diizinkan untuk dijebak kembali ke host. Solusi ini disebut sebagai penjaga MMIO .

Perangkat I/O virtual (virtio)

Virtio adalah standar yang populer, portabel, dan matang untuk mengimplementasikan dan berinteraksi dengan perangkat yang diparavirtualisasi. Mayoritas perangkat yang diekspos ke tamu yang dilindungi diimplementasikan menggunakan virtio. Virtio juga mendasari implementasi vsock yang digunakan untuk komunikasi antara tamu yang dilindungi dan seluruh Android.

Perangkat Virtio biasanya diimplementasikan di ruang pengguna host oleh VMM, yang mencegat akses memori yang terperangkap dari tamu ke antarmuka MMIO perangkat virtio dan mengemulasikan perilaku yang diharapkan. Akses MMIO relatif mahal karena setiap akses ke perangkat memerlukan perjalanan bolak-balik ke VMM dan sebaliknya, sehingga sebagian besar transfer data aktual antara perangkat dan tamu terjadi menggunakan sekumpulan virtqueues di memori. Asumsi utama dari virtio adalah bahwa host dapat mengakses memori tamu secara sewenang-wenang. Asumsi ini terlihat jelas dalam desain virtqueue, yang mungkin berisi petunjuk ke buffer di tamu yang ingin diakses secara langsung oleh emulasi perangkat.

Meskipun hypercall berbagi memori yang dijelaskan sebelumnya dapat digunakan untuk berbagi buffer data virtio dari tamu ke host, berbagi ini harus dilakukan pada granularitas halaman dan dapat mengekspos lebih banyak data daripada yang diperlukan jika ukuran buffer kurang dari ukuran halaman. . Sebaliknya, tamu dikonfigurasi untuk mengalokasikan virtqueues dan buffer data terkait dari jendela tetap memori bersama, dengan data disalin (terpental) ke dan dari jendela sesuai kebutuhan.

Interaksi dengan TrustZone

Meskipun tamu tidak dapat berinteraksi langsung dengan TrustZone, tuan rumah tetap harus dapat melakukan panggilan SMC ke dunia yang aman. Panggilan ini dapat menentukan buffer memori yang dialamatkan secara fisik yang tidak dapat diakses oleh host. Karena perangkat lunak aman umumnya tidak mengetahui aksesibilitas buffer, host jahat dapat menggunakan buffer ini untuk melakukan serangan deputi yang membingungkan (analog dengan serangan DMA). Untuk mencegah serangan tersebut, pKVM menjebak semua panggilan SMC host ke EL2 dan bertindak sebagai proxy antara host dan monitor aman di EL3.

Panggilan PSCI dari host diteruskan ke firmware EL3 dengan sedikit modifikasi. Secara khusus, titik masuk untuk CPU yang online atau melanjutkan dari penangguhan ditulis ulang sehingga tabel halaman tahap 2 diinstal di EL2 sebelum kembali ke host di EL1. Selama boot, perlindungan ini diterapkan oleh pKVM.

Arsitektur ini bergantung pada SoC yang mendukung PSCI, sebaiknya melalui penggunaan TF-A versi terbaru sebagai firmware EL3-nya.

Firmware Framework for Arm (FF-A) menstandardisasi interaksi antara dunia normal dan aman, khususnya dengan adanya hypervisor yang aman. Bagian utama dari spesifikasi mendefinisikan mekanisme untuk berbagi memori dengan dunia aman, menggunakan format pesan umum dan model izin yang ditentukan dengan baik untuk halaman yang mendasarinya. pKVM memproksi pesan FF-A untuk memastikan bahwa host tidak mencoba berbagi memori dengan sisi aman yang izinnya tidak memadai.

Arsitektur ini bergantung pada perangkat lunak dunia aman yang menerapkan model akses memori, untuk memastikan bahwa aplikasi tepercaya dan perangkat lunak lain yang berjalan di dunia aman dapat mengakses memori hanya jika memori tersebut dimiliki secara eksklusif oleh dunia aman atau telah dibagikan secara eksplisit menggunakan FF -A. Pada sistem dengan S-EL2, penerapan model akses memori harus dilakukan oleh Secure Partition Manager Core (SPMC), seperti Hafnium , yang mengelola tabel halaman tahap 2 untuk dunia yang aman. Pada sistem tanpa S-EL2, TEE dapat menerapkan model akses memori melalui tabel halaman tahap 1.

Jika panggilan SMC ke EL2 bukan panggilan PSCI atau pesan yang ditentukan FF-A, SMC yang tidak tertangani akan diteruskan ke EL3. Asumsinya adalah bahwa firmware aman (yang tentu tepercaya) dapat menangani SMC yang tidak ditangani dengan aman karena firmware tersebut memahami tindakan pencegahan yang diperlukan untuk mempertahankan isolasi pVM.

Pemantau mesin virtual

crosvm adalah monitor mesin virtual (VMM) yang menjalankan mesin virtual melalui antarmuka KVM Linux. Apa yang membuat crosvm unik adalah fokusnya pada keamanan dengan penggunaan bahasa pemrograman Rust dan kotak pasir di sekitar perangkat virtual untuk melindungi kernel host. Untuk informasi lebih lanjut tentang crosvm, lihat dokumentasi resminya di sini .

Deskriptor file dan ioctls

KVM memaparkan perangkat karakter /dev/kvm ke ruang pengguna dengan ioctls yang membentuk API KVM. Ioctl termasuk dalam kategori berikut:

• Sistem ioctls menanyakan dan mengatur atribut global yang memengaruhi seluruh subsistem KVM, dan membuat pVM.
• VM ioctls mengkueri dan mengatur atribut yang membuat CPU virtual (vCPU) dan perangkat, serta memengaruhi keseluruhan pVM, seperti termasuk tata letak memori dan jumlah CPU virtual (vCPU) dan perangkat.
• vCPU ioctls menanyakan dan mengatur atribut yang mengontrol pengoperasian satu CPU virtual.
• Kueri ioctls perangkat dan menyetel atribut yang mengontrol pengoperasian satu perangkat virtual.

Setiap proses crosvm menjalankan tepat satu instance mesin virtual. Proses ini menggunakan sistem KVM_CREATE_VM ioctl untuk membuat deskriptor file VM yang dapat digunakan untuk menerbitkan pVM ioctls. Ioctl KVM_CREATE_VCPU atau KVM_CREATE_DEVICE pada VM FD membuat vCPU/perangkat dan mengembalikan deskriptor file yang menunjuk ke sumber daya baru. ioctls pada vCPU atau perangkat FD dapat digunakan untuk mengontrol perangkat yang dibuat menggunakan ioctl pada VM FD. Untuk vCPU, ini termasuk tugas penting menjalankan kode tamu.

Secara internal, crosvm mendaftarkan deskriptor file VM dengan kernel menggunakan antarmuka epoll yang dipicu edge. Kernel kemudian memberitahukan crosvm setiap kali ada event baru yang tertunda di salah satu deskriptor file.

pKVM menambahkan kemampuan baru, KVM_CAP_ARM_PROTECTED_VM , yang dapat digunakan untuk mendapatkan informasi tentang lingkungan pVM dan menyiapkan mode terproteksi untuk VM. crosvm menggunakan ini selama pembuatan pVM jika flag --protected-vm diteruskan, untuk menanyakan dan mencadangkan jumlah memori yang sesuai untuk firmware pVM, lalu mengaktifkan mode terproteksi.

Alokasi memori

Salah satu tanggung jawab utama VMM adalah mengalokasikan memori VM dan mengelola tata letak memorinya. crosvm menghasilkan tata letak memori tetap yang dijelaskan secara longgar pada tabel di bawah.

Memori fisik dialokasikan dengan mmap dan memori disumbangkan ke VM untuk mengisi wilayah memorinya, yang disebut memslots , dengan KVM_SET_USER_MEMORY_REGION ioctl. Oleh karena itu, semua memori pVM tamu diatribusikan ke instance crosvm yang mengelolanya dan dapat mengakibatkan proses terhenti (menghentikan VM) jika host mulai kehabisan memori bebas. Ketika VM dihentikan, memori secara otomatis dihapus oleh hypervisor dan dikembalikan ke kernel host.

Di bawah KVM biasa, VMM mempertahankan akses ke semua memori tamu. Dengan pKVM, memori tamu tidak dipetakan dari ruang alamat fisik host saat disumbangkan ke tamu. Satu-satunya pengecualian adalah memori yang dibagikan kembali secara eksplisit oleh tamu, misalnya untuk perangkat virtio.

Wilayah MMIO di ruang alamat tamu tidak dipetakan. Akses ke wilayah ini oleh tamu terjebak dan mengakibatkan kejadian I/O di VM FD. Mekanisme ini digunakan untuk mengimplementasikan perangkat virtual. Dalam mode terlindungi, tamu harus mengetahui bahwa wilayah ruang alamatnya digunakan untuk MMIO menggunakan hypercall, untuk mengurangi risiko kebocoran informasi yang tidak disengaja.

Penjadwalan

Setiap CPU virtual diwakili oleh thread POSIX dan dijadwalkan oleh penjadwal host Linux. Thread memanggil ioctl KVM_RUN pada FD vCPU, sehingga hypervisor beralih ke konteks vCPU tamu. Penjadwal host memperhitungkan waktu yang dihabiskan dalam konteks tamu sebagai waktu yang digunakan oleh thread vCPU terkait. KVM_RUN kembali ketika ada kejadian yang harus ditangani oleh VMM, seperti I/O, akhir interupsi, atau vCPU dihentikan. VMM menangani kejadian tersebut dan memanggil KVM_RUN lagi.

Selama KVM_RUN , thread tetap dapat diakhiri oleh penjadwal host, kecuali untuk eksekusi kode hypervisor EL2, yang tidak dapat diakhiri. PVM tamu sendiri tidak memiliki mekanisme untuk mengendalikan perilaku ini.

Karena semua thread vCPU dijadwalkan seperti tugas ruang pengguna lainnya, thread tersebut tunduk pada semua mekanisme QoS standar. Secara khusus, setiap thread vCPU dapat dikaitkan ke CPU fisik, ditempatkan di cpuset, ditingkatkan atau dibatasi menggunakan penjepitan pemanfaatan, kebijakan prioritas/penjadwalannya diubah, dan banyak lagi.

Perangkat maya

crosvm mendukung sejumlah perangkat, termasuk yang berikut:

• virtio-blk untuk image disk komposit, baca-saja atau baca-tulis
• vhost-vsock untuk komunikasi dengan host
• virtio-pci sebagai transportasi virtio
• pl030 jam waktu nyata (RTC)
• 16550a UART untuk komunikasi serial

firmware pVM

Firmware pVM (pvmfw) adalah kode pertama yang dijalankan oleh pVM, mirip dengan ROM boot perangkat fisik. Tujuan utama pvmfw adalah melakukan bootstrap boot aman dan mendapatkan rahasia unik pVM. pvmfw tidak terbatas untuk digunakan dengan OS tertentu, seperti Microdroid , selama OS tersebut didukung oleh crosvm dan telah ditandatangani dengan benar.

Biner pvmfw disimpan dalam partisi flash dengan nama yang sama dan diperbarui menggunakan OTA .

Booting perangkat

Urutan langkah berikut ditambahkan ke prosedur booting perangkat yang mendukung pKVM:

1. Android Bootloader (ABL) memuat pvmfw dari partisinya ke dalam memori dan memverifikasi gambar.
2. ABL memperoleh rahasia Device Identifier Composition Engine (DICE) (Compound Device Identifiers (CDI) dan Boot Certificate Chain (BCC)) dari Root of Trust.
3. ABL melakukan pengukuran dan derivasi DICE dari rahasia pvmfw (CDI), dan menambahkannya ke biner pvmfw.
4. ABL menambahkan node wilayah memori cadangan linux,pkvm-guest-firmware-memory ke DT, menjelaskan lokasi dan ukuran biner pvmfw serta rahasia yang diperolehnya pada langkah sebelumnya.
5. ABL menyerahkan kendali ke Linux dan Linux menginisialisasi pKVM.
6. pKVM membuka peta wilayah memori pvmfw dari tabel halaman tahap 2 host dan melindunginya dari host (dan tamu) sepanjang waktu aktif perangkat.

Setelah perangkat di-boot, Microdroid di-boot sesuai langkah-langkah di bagian Urutan boot pada dokumen Microdroid .

boot pVM

Saat membuat pVM, crosvm (atau VMM lainnya) harus membuat memslot yang cukup besar untuk diisi dengan gambar pvmfw oleh hypervisor. VMM juga dibatasi dalam daftar register yang nilai awalnya dapat ditetapkan (x0-x14 untuk vCPU primer, tidak ada untuk vCPU sekunder). Register yang tersisa dicadangkan dan merupakan bagian dari ABI hypervisor-pvmfw.

Saat pVM dijalankan, hypervisor pertama-tama menyerahkan kendali vCPU utama ke pvmfw. Firmware mengharapkan crosvm memuat kernel bertanda AVB, yang dapat berupa bootloader atau image lainnya, dan FDT yang tidak ditandatangani ke memori pada offset yang diketahui. pvmfw memvalidasi tanda tangan AVB dan, jika berhasil, menghasilkan pohon perangkat tepercaya dari FDT yang diterima, menghapus rahasianya dari memori, dan bercabang ke titik masuk payload. Jika salah satu langkah verifikasi gagal, firmware mengeluarkan hypercall PSCI SYSTEM_RESET .

Di antara boot, informasi tentang instance pVM disimpan dalam partisi (perangkat virtio-blk) dan dienkripsi dengan rahasia pvmfw untuk memastikan bahwa, setelah reboot, rahasia tersebut disediakan ke instance yang benar.