Arsitektur AVF

Android menyediakan implementasi referensi semua komponen yang diperlukan untuk mengimplementasikan Framework Virtualisasi Android. Saat ini, implementasi ini terbatas pada ARM64. Halaman ini menjelaskan arsitektur framework.

Latar belakang

Arsitektur Arm mengizinkan hingga empat level pengecualian, dengan pengecualian level 0 (EL0) menjadi yang paling tidak memiliki hak istimewa, dan paling banyak pengecualian level 3 (EL3). Bagian terbesar codebase Android (semua komponen userspace) berjalan di EL0. Bagian lainnya yang umumnya disebut "Android" adalah kernel Linux, yang berjalan di EL1.

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

Hypervisor

Virtual machine berbasis kernel (pKVM) yang dilindungi dibangun berdasarkan hypervisor KVM Linux, yang telah diperluas dengan kemampuan untuk membatasi akses ke payload yang berjalan di virtual machine tamu yang ditandai 'terlindungi' pada saat pembuatan.

KVM/arm64 mendukung mode eksekusi yang berbeda bergantung pada ketersediaan fitur CPU tertentu, yaitu Virtualization Host Extensions (VHE) (ARMv8.1 dan yang lebih baru). Dalam salah satu mode tersebut, biasanya dikenal sebagai mode non-VHE, kode hypervisor dibagi dari image kernel selama booting dan diinstal di EL2, sedangkan kernel itu sendiri berjalan di EL1. Meskipun merupakan bagian dari codebase Linux, komponen EL2 dari KVM adalah komponen kecil yang bertanggung jawab atas peralihan antara beberapa EL1. Komponen hypervisor dikompilasi dengan Linux, tetapi berada di bagian memori khusus yang terpisah dari gambar vmlinux. pKVM memanfaatkan desain ini dengan memperluas kode hypervisor dengan 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 hardware yang berisi fungsi khusus perangkat, seperti driver input-output memory management unit (IOMMU). Modul ini memungkinkan Anda mem-port 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 booting pKVM:

1. Bootloader memasuki kernel generik di EL2.
2. Kernel generik mendeteksi bahwa ia berjalan pada EL2 dan mencabut hak istimewa dirinya sendiri ke EL1 sementara pKVM dan modulnya terus berjalan di EL2. Selain itu, modul vendor pKVM dimuat saat ini.
3. Kernel generik akan melanjutkan booting secara normal, memuat semua driver perangkat yang diperlukan hingga mencapai ruang pengguna. Pada titik ini, pKVM sudah diterapkan dan menangani tabel paging tahap 2.

Prosedur booting memercayai bootloader untuk mempertahankan integritas image kernel hanya selama booting awal. Jika diturunkan hak istimewanya, kernel tidak lagi dianggap dipercaya oleh hypervisor, yang kemudian bertanggung jawab untuk melindungi dirinya sendiri meskipun kernel disusupi.

Memiliki kernel Android dan hypervisor dalam image biner yang sama memungkinkan antarmuka komunikasi yang terkait erat di antara keduanya. Pengaitan erat ini menjamin update atomik kedua komponen, sehingga menghindari kebutuhan untuk menjaga antarmuka di antara keduanya tetap stabil, dan menawarkan banyak fleksibilitas tanpa mengorbankan pengelolaan jangka panjang. Pengaitan erat juga memungkinkan pengoptimalan performa saat kedua komponen dapat bekerja sama tanpa memengaruhi jaminan keamanan yang disediakan oleh hypervisor.

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

Perlindungan akses memori CPU

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

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

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

KVM memanfaatkan sepenuhnya penafsiran alamat pada tahap 2 untuk menerapkan pemetaan IPA/PA yang kompleks bagi tamu, yang menciptakan ilusi memori yang berdekatan bagi tamu meskipun terjadi fragmentasi fisik. Namun, penggunaan MMU tahap 2 untuk host dibatasi hanya untuk kontrol akses. Tahap host 2 dipetakan identitas, yang memastikan bahwa memori yang berdekatan di ruang IPA host berdekatan dalam ruang PA. Arsitektur ini memungkinkan penggunaan pemetaan besar dalam tabel halaman sehingga mengurangi tekanan pada buffer tampak samping terjemahan (TLB). Karena pemetaan identitas dapat diindeks oleh PA, tahap host 2 juga digunakan untuk melacak kepemilikan halaman secara langsung di tabel halaman.

Perlindungan akses memori langsung (DMA)

Seperti yang dijelaskan sebelumnya, menghapus pemetaan halaman tamu dari host Linux di tabel halaman CPU adalah langkah yang diperlukan, tetapi tidak memadai untuk melindungi memori tamu. pKVM juga perlu memberikan perlindungan terhadap akses memori yang dibuat oleh perangkat yang mendukung DMA di bawah kontrol kernel host, dan kemungkinan serangan DMA yang dimulai oleh host berbahaya. Untuk mencegah perangkat tersebut mengakses memori tamu, pKVM memerlukan hardware unit manajemen memori input-output (IOMMU) untuk setiap perangkat yang mendukung DMA dalam sistem, seperti ditunjukkan pada gambar 3.

Setidaknya, hardware IOMMU menyediakan cara untuk memberikan dan mencabut akses baca/tulis bagi perangkat ke memori fisik pada perincian halaman. Namun, hardware IOMMU ini membatasi penggunaan perangkat dalam pVM karena memiliki tahap 2 yang dipetakan identitasnya.

Untuk memastikan isolasi antar-virtual machine, transaksi memori yang dihasilkan atas nama entity yang berbeda harus dapat dibedakan oleh IOMMU sehingga kumpulan tabel halaman yang tepat dapat digunakan untuk terjemahan.

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

Namun, menempatkan host yang mengontrol status perangkat akan menempatkan persyaratan tambahan pada antarmuka pemrograman hardware IOMMU untuk memastikan bahwa pemeriksaan izin tidak dapat diabaikan dengan cara lain, misalnya, setelah reset perangkat.

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

Kepemilikan memori

Pada saat booting, semua memori non-hypervisor dianggap dimiliki oleh host, dan dilacak sedemikian rupa oleh hypervisor. Saat pVM muncul, host akan mendonasikan halaman memori untuk memungkinkannya melakukan booting, dan hypervisor akan mentransisikan kepemilikan halaman tersebut dari host ke pVM. Dengan demikian, hypervisor menerapkan pembatasan kontrol akses di tabel halaman tahap 2 host untuk mencegahnya mengakses halaman lagi, sehingga memberikan kerahasiaan kepada tamu.

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

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

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

Host harus memastikan bahwa ia tidak mencoba mengakses halaman yang tidak dapat diakses oleh hypervisor. Akses host ilegal menyebabkan pengecualian sinkron diinjeksikan ke host oleh hypervisor, yang dapat menyebabkan tugas userspace yang bertanggung jawab menerima sinyal SEGV, atau kernel host mengalami error. Untuk mencegah akses yang tidak disengaja, halaman yang didonasikan kepada tamu tidak memenuhi syarat untuk ditukar atau digabungkan oleh kernel host.

Penanganan gangguan dan timer

Gangguan adalah bagian penting dari cara tamu berinteraksi dengan perangkat dan untuk komunikasi antar-CPU, dengan interupsi interprosesor (IPI) adalah mekanisme komunikasi utamanya. Model KVM berfungsi mendelegasikan semua manajemen interupsi virtual ke host di EL1, yang untuk tujuan tersebut berperilaku sebagai bagian yang tidak tepercaya dari hypervisor.

pKVM menawarkan emulasi Generic Interrupt Controller versi 3 (GICv3) lengkap berdasarkan kode KVM yang sudah 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 terlihat oleh host EL1, termasuk salinan register hypervisor yang terkait dengan interupsi. Visibilitas ini biasanya dicapai menggunakan region memori bersama, satu per CPU virtual (vCPU).

Kode dukungan runtime pendaftaran sistem dapat disederhanakan untuk hanya mendukung penyusunan daftar Software Generated Interrupt Register (SGIR) dan Nonaktifkan Interrupt Register (DIR). Arsitektur ini mewajibkan pendaftaran ini selalu menjebak ke EL2, sedangkan jebakan lainnya sejauh ini hanya berguna untuk mengurangi error. Segala sesuatu yang lain ditangani di hardware.

Di sisi MMIO, semuanya diemulasikan di EL1, menggunakan kembali semua infrastruktur saat ini di KVM. Terakhir, Tunggu Interupsi (WFI) selalu diteruskan ke EL1, karena ini adalah salah satu primitif penjadwalan dasar yang digunakan KVM.

Dukungan timer

Nilai pembanding untuk timer virtual harus diekspos ke EL1 pada setiap WFI penangkap sehingga EL1 dapat memasukkan timer dan mengganggu saat vCPU diblokir. Timer fisik sepenuhnya diemulasikan, dan semua jebakan diteruskan ke EL1.

Penanganan MMIO

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

• IPA dan ukuran akses
• Data jika terjadi operasi tulis
• Endianness CPU saat terjebak

Selain itu, perangkap dengan register tujuan umum (GPR) sebagai sumber/tujuan direlai menggunakan pendaftaran semu transfer abstrak.

Antarmuka tamu

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

Hypercall umum

• PSCI menyediakan mekanisme standar bagi tamu untuk mengontrol siklus proses vCPU-nya, termasuk onlining, offline, dan shutdown sistem.
• TRNG menyediakan mekanisme standar bagi tamu untuk meminta entropi dari pKVM yang merelai panggilan ke EL3. Mekanisme ini sangat berguna jika host tidak dapat dipercaya untuk memvirtualisasikan generator angka acak hardware (RNG).

Hypercall pKVM

• Berbagi memori dengan host. Semua memori tamu pada awalnya tidak dapat diakses oleh host, tetapi 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 menentukan dengan tepat bagian memori yang dapat diakses oleh seluruh Android tanpa perlu handshake.
• Pelepasan memori ke host. Semua memori tamu biasanya milik tamu sampai dihancurkan. Status ini mungkin tidak memadai untuk VM berumur panjang dengan persyaratan memori yang berubah dari waktu ke waktu. Hypercall relinquish memungkinkan tamu mentransfer kepemilikan halaman secara eksplisit kembali ke host tanpa memerlukan penghentian dari tamu.
• Menjebak akses memori ke {i>host<i}. Biasanya, jika tamu KVM mengakses alamat yang tidak sesuai dengan region memori yang valid, thread vCPU akan keluar ke host dan akses tersebut biasanya digunakan untuk MMIO serta diemulasikan oleh VMM di ruang pengguna. Untuk memfasilitasi penanganan ini, pKVM diperlukan untuk memberitahukan detail tentang petunjuk faulting seperti alamatnya, mendaftarkan parameter, dan kemungkinan kontennya kembali ke host, yang dapat secara tidak sengaja mengekspos data sensitif dari tamu yang dilindungi jika jebakan tersebut tidak diantisipasi. pKVM mengatasi masalah ini dengan memperlakukan kesalahan ini sebagai fatal kecuali jika tamu sebelumnya telah mengeluarkan hypercall untuk mengidentifikasi perangkap IPA yang salah ke host mana yang diizinkan untuk mengakses kembali perangkap IPA mana yang diizinkan. Solusi ini disebut sebagai MMIO guard.

Perangkat I/O virtual (virtio)

Virtio adalah standar yang populer, portabel, dan matang untuk mengimplementasikan dan berinteraksi dengan perangkat paravirtualisasi. Mayoritas perangkat yang terekspos ke tamu yang dilindungi diimplementasikan dengan menggunakan virtio. Virtio juga mendukung 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 kembali, sehingga sebagian besar transfer data aktual antara perangkat dan tamu terjadi menggunakan serangkaian kebajikan dalam memori. Asumsi utama virtio adalah host dapat mengakses memori tamu secara arbitrer. Asumsi ini terlihat dalam desain sifat tersebut, yang mungkin berisi pointer ke buffer pada tamu yang akan diakses secara langsung oleh emulasi perangkat.

Meskipun hypercall berbagi memori yang dijelaskan sebelumnya dapat digunakan untuk berbagi buffer data virtio dari tamu ke host, pembagian ini harus dilakukan pada perincian halaman dan pada akhirnya dapat mengekspos lebih banyak data daripada yang diperlukan jika ukuran buffer kurang dari ukuran halaman. Sebagai gantinya, tamu dikonfigurasi untuk mengalokasikan layanan dan buffer data terkait dari periode tetap dalam memori bersama, dengan data disalin (dipantulkan) ke dan dari jendela sesuai kebutuhan.

Interaksi dengan TrustZone

Meskipun tamu tidak dapat berinteraksi langsung dengan TrustZone, host tetap harus dapat melakukan panggilan SMC ke lingkungan yang aman. Panggilan ini dapat menentukan buffer memori yang dialamatkan secara fisik yang tidak dapat diakses oleh host. Karena software yang aman umumnya tidak mengetahui aksesibilitas buffer, host berbahaya dapat menggunakan buffer ini untuk melakukan serangan deputi yang bingung (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 modifikasi minimal. Secara khusus, titik entri 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 booting, perlindungan ini diberlakukan oleh pKVM.

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

Firmware Framework for Arm (FF-A) menstandarkan interaksi antara dunia normal dan aman, terutama dengan adanya hypervisor yang aman. Sebagian besar spesifikasi ini menentukan mekanisme untuk berbagi memori dengan sistem keamanan, menggunakan format pesan umum dan model izin yang didefinisikan dengan baik untuk halaman dasar. pKVM memberikan proxy pesan FF-A untuk memastikan bahwa host tidak mencoba berbagi memori dengan sisi aman yang tidak memiliki izin yang memadai.

Arsitektur ini mengandalkan software dunia aman yang menerapkan model akses memori, untuk memastikan bahwa aplikasi tepercaya dan software lain yang berjalan di dunia aman dapat mengakses memori hanya jika memori tersebut dimiliki secara eksklusif oleh penyedia 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 mempertahankan tabel halaman tahap 2 untuk keamanan. 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 firmware aman (yang harus dipercaya) dapat menangani SMC yang tidak tertangani dengan aman karena firmware memahami tindakan pencegahan yang diperlukan untuk mempertahankan isolasi pVM.

Monitor virtual machine

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

Deskriptor file dan ioctls

KVM mengekspos perangkat karakter /dev/kvm ke ruang pengguna dengan ioctls yang menyusun KVM API. Setiap ioctls termasuk dalam kategori berikut:

• ioctl sistem mengkueri dan menetapkan atribut global yang memengaruhi seluruh subsistem KVM, serta membuat pVM.
• ioctl VM mengkueri dan menetapkan atribut yang membuat CPU (vCPU) dan perangkat virtual, serta memengaruhi seluruh pVM, seperti termasuk tata letak memori dan jumlah CPU virtual (vCPU) dan perangkat.
• vCPU ioctls mengkueri dan menetapkan atribut yang mengontrol operasi satu CPU virtual.
• Perangkat ioctls mengkueri dan menetapkan atribut yang mengontrol operasi satu perangkat virtual.

Setiap proses crosvm menjalankan tepat satu instance virtual machine. Proses ini menggunakan ioctl sistem KVM_CREATE_VM untuk membuat deskriptor file VM yang dapat digunakan untuk menerbitkan ioctl pVM. Perintah KVM_CREATE_VCPU atau KVM_CREATE_DEVICE pada FD VM membuat vCPU/perangkat dan menampilkan deskriptor file yang mengarah ke resource baru. ioctl pada vCPU atau FD perangkat dapat digunakan untuk mengontrol perangkat yang dibuat menggunakan ioctl pada VM FD. Untuk vCPU, hal ini termasuk tugas penting untuk menjalankan kode tamu.

Secara internal, crosvm mendaftarkan deskriptor file VM dengan kernel menggunakan antarmuka epoll yang dipicu edge. Kernel kemudian memberi tahu crosvm setiap kali ada peristiwa baru yang tertunda di deskriptor file.

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

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 dalam tabel di bawah ini.

FDT dalam mode normal	PHYS_MEMORY_END - 0x200000
Kosongkan	...
{i>Raddisk<i}	ALIGN_UP(KERNEL_END, 0x1000000)
Kernel	0x80080000
{i>Bootloader<i}	0x80200000
FDT dalam mode BIOS	0x80000000
Basis memori fisik	0x80000000
Firmware pVM	0x7FE00000
Memori perangkat	0x10000 - 0x40000000

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

Pada KVM reguler, VMM mempertahankan akses ke semua memori tamu. Dengan pKVM, memori tamu tidak dipetakan dari ruang alamat fisik host saat didonasikan kepada tamu. Satu-satunya pengecualian adalah memori yang secara eksplisit dibagikan kembali oleh tamu, seperti untuk perangkat virtio.

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

Penjadwalan

Setiap CPU virtual direpresentasikan oleh thread POSIX dan dijadwalkan oleh penjadwal Linux host. Thread memanggil ioctl KVM_RUN pada FD vCPU, yang mengakibatkan hypervisor beralih ke konteks vCPU tamu. Penjadwal host memperhitungkan waktu yang dihabiskan dalam konteks tamu sebagai waktu yang digunakan oleh thread vCPU yang sesuai. KVM_RUN ditampilkan saat terjadi peristiwa yang harus ditangani oleh VMM, seperti I/O, penghentian gangguan, atau vCPU dihentikan. VMM menangani peristiwa dan memanggil KVM_RUN lagi.

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

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

Perangkat virtual

crosvm mendukung sejumlah perangkat, termasuk yang berikut:

• virtio-blk untuk {i>image disk<i} komposit, hanya-baca atau baca-tulis
• vhost-vsock untuk komunikasi dengan host
• virtio-pci sebagai transpor virtio
• Jam real time pl030 (RTC)
• 16550a UART untuk komunikasi serial

Firmware pVM

Firmware pVM (pvmfw) adalah kode pertama yang dieksekusi oleh pVM, mirip dengan ROM booting perangkat fisik. Tujuan utama pvmfw adalah mem-bootstrap booting aman dan memperoleh rahasia unik pVM. pvmfw tidak dibatasi untuk digunakan dengan OS tertentu, seperti Microdroid, selama OS didukung dan oleh croid telah ditandatangani dengan benar.

Biner pvmfw disimpan dalam partisi flash dengan nama yang sama dan diupdate 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 mendapatkan rahasia Mesin Komposisi ID Perangkat (DICE) (ID Perangkat Compound (CDI) dan rantai sertifikat DICE) dari Root of Trust.
3. ABL memperoleh CDI yang diperlukan untuk pvmfw, dan menambahkannya ke biner pvmfw.
4. ABL menambahkan node region memori yang dicadangkan linux,pkvm-guest-firmware-memory ke DT, yang menjelaskan lokasi dan ukuran biner pvmfw serta rahasia yang diperolehnya pada langkah sebelumnya.
5. ABL menyerahkan kontrol langsung ke Linux dan Linux melakukan inisialisasi pKVM.
6. pKVM membuka pemetaan region memori pvmfw dari tabel halaman tahap 2 host dan melindunginya dari host (dan tamu) selama waktu beroperasi perangkat.

Setelah booting perangkat, Microdroid di-booting sesuai langkah-langkah di bagian Urutan booting dalam dokumen Microdroid.

booting pVM

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

Saat pVM dijalankan, hypervisor akan terlebih dahulu menyerahkan kontrol vCPU utama ke pvmfw. Firmware ini memperkirakan crosvm telah memuat kernel bertanda AVB, yang dapat berupa bootloader atau image lain, dan FDT yang tidak ditandatangani ke memori pada offset yang diketahui. pvmfw memvalidasi tanda tangan AVB dan, jika berhasil, membuat hierarki perangkat tepercaya dari FDT yang diterima, menghapus total rahasianya dari memori, dan bercabang ke titik entri payload. Jika salah satu langkah verifikasi gagal, firmware akan mengeluarkan hypercall SYSTEM_RESET PSCI.

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