Android menyediakan implementasi referensi semua komponen yang diperlukan untuk mengimplementasikan Framework Virtualisasi Android. Saat ini, penerapan ini dibatasi untuk ARM64. Halaman ini menjelaskan arsitektur framework.
Latar belakang
Arsitektur Arm memungkinkan hingga empat level pengecualian, dengan level pengecualian 0 (EL0) yang paling sedikit memiliki hak istimewa, dan level pengecualian 3 (EL3) yang paling banyak. Bagian terbesar codebase Android (semua komponen ruang pengguna) berjalan di EL0. Bagian lain yang biasa 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 yang dilindungi (pKVM) dibuat berdasarkan hypervisor Linux KVM, yang telah diperluas dengan kemampuan untuk membatasi akses ke payload yang berjalan di virtual machine tamu yang ditandai 'dilindungi' pada saat pembuatan.
KVM/arm64 mendukung berbagai mode eksekusi 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 sehingga dapat 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 unit pengelolaan memori input-output (IOMMU). Modul ini memungkinkan Anda mem-port fitur keamanan yang memerlukan akses level pengecualian 2 (EL2) ke pKVM.
Untuk mempelajari cara menerapkan dan memuat modul vendor pKVM, lihat Menerapkan modul vendor pKVM.
Prosedur booting
Gambar berikut menggambarkan prosedur booting pKVM:
- Bootloader memasuki kernel generik di EL2.
- 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.
- Kernel generik akan melanjutkan booting secara normal, memuat semua driver perangkat yang diperlukan hingga mencapai ruang pengguna. Pada tahap ini, pKVM sudah ada dan menangani tabel halaman 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.
Dengan memiliki kernel Android dan hypervisor dalam image biner yang sama, antarmuka komunikasi yang sangat erat antara keduanya dapat dilakukan. Penggabungan yang erat ini menjamin update atomik dari kedua komponen, sehingga tidak perlu mempertahankan antarmuka di antara keduanya agar stabil, dan menawarkan banyak fleksibilitas tanpa mengorbankan kemampuan pemeliharaan jangka panjang. Penggabungan yang erat juga memungkinkan pengoptimalan performa saat kedua komponen dapat bekerja sama tanpa memengaruhi jaminan keamanan yang disediakan oleh hypervisor.
Selain itu, penerapan 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 menjadi dua tahap independen, yang keduanya dapat digunakan untuk menerapkan 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 ruang pengguna dan untuk ruang alamat virtualnya sendiri.
MMU tahap 2 dikontrol oleh EL2 dan memungkinkan penerapan terjemahan alamat kedua pada alamat output MMU tahap 1, yang 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, saat kedua tahap terjemahan diaktifkan, alamat output dari tahap 1 disebut alamat fisik perantara (IPA) Catatan: Alamat virtual (VA) diterjemahkan menjadi IPA, lalu menjadi 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 untuk melewati MMU tahap 2, sehingga memungkinkan akses yang tidak dibatasi dari host ke halaman memori tamu. Di sisi lain, pKVM memungkinkan perlindungan tahap 2 bahkan dalam konteks host, dan menempatkan hypervisor yang bertanggung jawab untuk melindungi halaman memori tamu, bukan host.
KVM memanfaatkan sepenuhnya terjemahan 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 2 host dipetakan identitas, yang memastikan bahwa memori yang berurutan di ruang IPA host berurutan di ruang PA. Arsitektur ini memungkinkan penggunaan pemetaan besar dalam tabel halaman dan akibatnya mengurangi tekanan pada buffering tampilan terjemahan (TLB). Karena pemetaan identitas dapat diindeks oleh PA, host stage 2 juga digunakan untuk melacak kepemilikan halaman secara langsung di tabel halaman.
Perlindungan akses memori langsung (DMA)
Seperti yang dijelaskan sebelumnya, membatalkan pemetaan halaman tamu dari host Linux di tabel halaman CPU adalah langkah yang diperlukan, tetapi tidak memadai untuk melindungi memori tamu. pKVM juga perlu melindungi terhadap akses memori yang dilakukan oleh perangkat yang kompatibel dengan 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 pengelolaan memori input-output (IOMMU) untuk setiap perangkat yang kompatibel dengan DMA dalam sistem, seperti yang ditunjukkan pada gambar 3.
Minimal, hardware IOMMU menyediakan cara untuk memberikan dan mencabut akses baca/tulis untuk perangkat ke memori fisik pada tingkat perincian halaman. Namun, hardware IOMMU ini membatasi penggunaan perangkat di pVM karena mengasumsikan tahap 2 yang dipetakan identitas.
Untuk memastikan isolasi antar-virtual machine, transaksi memori yang dihasilkan atas nama entitas yang berbeda harus dapat dibedakan oleh IOMMU sehingga kumpulan tabel halaman yang sesuai dapat digunakan untuk terjemahan.
Selain itu, mengurangi jumlah kode khusus SoC di EL2 adalah strategi utama untuk mengurangi keseluruhan trusted computing base (TCB) pKVM dan bertentangan dengan penyertaan driver IOMMU dalam 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 dalam kontrol 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 isolasi dan penetapan langsung adalah arsitektur Arm System Memory Management Unit (SMMU). Arsitektur ini adalah solusi referensi yang direkomendasikan.
Kepemilikan memori
Pada waktu booting, semua memori non-hypervisor diasumsikan dimiliki oleh host, dan dilacak oleh hypervisor. Saat pVM dibuat, host akan menyumbangkan halaman memori agar dapat 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 mencegah hypervisor 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 kembali beberapa halaman mereka kepada host menggunakan hypercall, yang menginstruksikan hypervisor untuk memetakan ulang halaman tersebut di tabel halaman tahap 2 host. Demikian pula, komunikasi host dengan TrustZone dimungkinkan oleh operasi berbagi dan/atau peminjaman memori, yang semuanya dipantau dan dikontrol dengan cermat 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 agar pVM 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 entitas 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, dicadangkan untuk penggunaan software.
Host harus memastikan bahwa host tidak mencoba mengakses halaman yang telah dibuat tidak dapat diakses oleh hypervisor. Akses host ilegal menyebabkan pengecualian sinkron dimasukkan ke host oleh hypervisor, yang dapat mengakibatkan tugas ruang pengguna 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
Interupsi adalah bagian penting dari cara tamu berinteraksi dengan perangkat dan untuk komunikasi antar-CPU, dengan interupsi interprosesor (IPI) sebagai mekanisme komunikasi utama. Model KVM adalah mendelegasikan semua pengelolaan 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 dilakukan menggunakan region memori bersama, satu region per CPU virtual (vCPU).
Kode dukungan runtime register sistem dapat disederhanakan untuk hanya mendukung trapping register Software Generated Interrupt Register (SGIR) dan Deactivate Interrupt Register (DIR). Arsitektur mewajibkan register ini selalu memicu EL2, sedangkan perangkap lainnya sejauh ini hanya berguna untuk mengurangi errata. Semua yang lain ditangani di hardware.
Di sisi MMIO, semuanya diemulasi di EL1, yang menggunakan kembali semua infrastruktur saat ini di KVM. Terakhir, Wait for Interrupt (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 perangkap sehingga EL1 dapat memasukkan interupsi timer 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 diteruskan menggunakan pseudo-register 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 untuk tamu pKVM.
Hypercall generik
- 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 meneruskan 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 awalnya tidak dapat diakses oleh host, tetapi akses host diperlukan untuk komunikasi memori bersama dan untuk perangkat paravirtual 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 hingga dihancurkan. Status ini mungkin tidak memadai untuk VM berumur
panjang dengan persyaratan memori yang berubah dari waktu ke waktu. Hypercall
relinquishmemungkinkan tamu mentransfer kepemilikan halaman secara eksplisit kembali ke host tanpa memerlukan penghentian dari tamu. - Perangkap akses memori ke host. Secara tradisional, jika tamu KVM mengakses alamat yang tidak sesuai dengan region memori yang valid, thread vCPU akan keluar ke host dan akses biasanya digunakan untuk MMIO dan di-emulasi 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 untuk host kembali ke host yang diizinkan ke host kembali ke host 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. Sebagian besar perangkat yang diekspos ke tamu yang dilindungi diimplementasikan menggunakan virtio. Virtio juga mendukung penerapan vsock yang digunakan untuk komunikasi antara tamu yang dilindungi dan Android lainnya.
Perangkat virtio biasanya diterapkan di ruang pengguna host oleh VMM, yang menangkap akses memori yang terperangkap dari tamu ke antarmuka MMIO perangkat virtio dan mengemulasi 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 sebenarnya antara perangkat dan tamu terjadi menggunakan kumpulan virtqueue dalam memori. Asumsi utama virtio adalah host dapat mengakses memori tamu secara arbitrer. Asumsi ini terlihat dalam desain virtqueue, yang mungkin berisi pointer ke buffer di tamu yang dimaksudkan untuk diakses secara langsung oleh emulasi perangkat.
Meskipun hypercall berbagi memori yang dijelaskan sebelumnya dapat digunakan untuk membagikan buffering data virtio dari tamu ke host, berbagi ini harus dilakukan pada tingkat perincian halaman dan dapat berakhir dengan mengekspos lebih banyak data dari yang diperlukan jika ukuran buffering kurang dari ukuran halaman. Sebagai gantinya, tamu dikonfigurasi untuk mengalokasikan virtqueue dan buffering data yang sesuai dari jendela memori bersama yang tetap, dengan data disalin (di-bounce) 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 diterapkan oleh pKVM.
Arsitektur ini mengandalkan SoC yang mendukung PSCI, sebaiknya melalui penggunaan versi terbaru TF-A sebagai firmware EL3-nya.
Framework Firmware untuk Arm (FF-A) menstandarkan interaksi antara dunia normal dan aman, terutama dengan adanya hypervisor aman. Sebagian besar spesifikasi menentukan mekanisme untuk berbagi memori dengan dunia yang aman, menggunakan format pesan umum dan model izin yang ditentukan dengan baik untuk halaman yang mendasarinya. pKVM mem-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 secure world yang menerapkan model akses memori, untuk memastikan bahwa aplikasi tepercaya dan software lainnya yang berjalan di secure world hanya dapat mengakses memori jika dimiliki secara eksklusif oleh secure world atau telah dibagikan secara eksplisit dengan 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 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 ditangani 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.
Virtual machine monitor
crosvm adalah virtual machine monitor (VMM) yang menjalankan virtual machine 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 ioctl
KVM mengekspos perangkat karakter /dev/kvm ke ruang pengguna dengan ioctl yang membentuk
KVM API. IOCTL termasuk dalam kategori berikut:
- IOCtl sistem membuat kueri dan menetapkan atribut global yang memengaruhi seluruh subsistem KVM, dan 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.
- IOCtl perangkat membuat kueri dan menetapkan atribut yang mengontrol operasi satu perangkat virtual.
Setiap proses crosvm menjalankan tepat satu instance mesin virtual. Proses ini
menggunakan ioctl sistem KVM_CREATE_VM untuk membuat deskripsi file VM yang dapat
digunakan untuk menerbitkan ioctl pVM. IOCtl KVM_CREATE_VCPU atau KVM_CREATE_DEVICE
di FD VM membuat vCPU/perangkat dan menampilkan deskripsi file yang mengarah ke
resource baru. IOCtl di vCPU atau FD perangkat dapat digunakan untuk mengontrol perangkat
yang dibuat menggunakan IOCtl di FD VM. Untuk vCPU, hal ini mencakup
tugas penting dalam menjalankan kode tamu.
Secara internal, crosvm mendaftarkan deskriptor file VM dengan kernel menggunakan
antarmuka epoll yang dipicu edge. Kernel kemudian akan memberi tahu crosvm setiap kali
ada peristiwa baru yang tertunda di deskriptor file mana pun.
pKVM menambahkan kemampuan baru, KVM_CAP_ARM_PROTECTED_VM, yang dapat digunakan untuk
mendapatkan informasi tentang lingkungan pVM dan menyiapkan mode perlindungan untuk VM.
crosvm menggunakannya selama pembuatan pVM jika flag --protected-vm diteruskan,
untuk membuat kueri dan mencadangkan jumlah memori yang sesuai untuk
firmware pVM, lalu mengaktifkan mode perlindungan.
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 | ...
|
| Ramdisk | ALIGN_UP(KERNEL_END, 0x1000000)
|
| Kernel | 0x80080000
|
| Bootloader | 0x80200000
|
| FDT dalam mode BIOS | 0x80000000
|
| Dasar 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 menyebabkan
proses dihentikan (mengakhiri VM) jika host mulai kehabisan
memori kosong. Saat VM dihentikan, memori akan otomatis dihapus oleh
hypervisor dan dikembalikan ke kernel host.
Di KVM reguler, VMM mempertahankan akses ke semua memori tamu. Dengan pKVM, memori tamu tidak dipetakan dari ruang alamat fisik host saat didonorkan ke tamu. Satu-satunya pengecualian adalah memori yang dibagikan kembali secara eksplisit oleh tamu, seperti untuk perangkat virtio.
Region MMIO di ruang alamat tamu tidak dipetakan. Akses ke wilayah ini oleh tamu terperangkap dan menghasilkan 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 diwakili 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
mempertimbangkan waktu yang dihabiskan dalam konteks tamu sebagai waktu yang digunakan oleh thread
vCPU yang sesuai. KVM_RUN ditampilkan saat ada peristiwa yang harus ditangani oleh
VMM, seperti I/O, akhir interupsi, 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
itu sendiri tidak memiliki mekanisme untuk mengontrol 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 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 image disk gabungan, 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. Sasaran utama pvmfw adalah untuk melakukan bootstrap secure boot dan mendapatkan secret unik pVM. pvmfw tidak terbatas untuk digunakan dengan OS tertentu, seperti Microdroid, selama OS didukung oleh crosvm dan telah ditandatangani dengan benar.
Biner pvmfw disimpan di partisi flash dengan nama yang sama dan diupdate menggunakan OTA.
Booting perangkat
Urutan langkah berikut ditambahkan ke prosedur booting perangkat yang kompatibel dengan pKVM:
- Android Bootloader (ABL) memuat pvmfw dari partisinya ke dalam memori dan memverifikasi image.
- ABL mendapatkan rahasia Device Identifier Composition Engine (DICE) (Compound Device Identifiers (CDI) dan rantai sertifikat DICE) dari Root of Trust.
- ABL memperoleh CDI yang diperlukan untuk pvmfw, dan menambahkannya ke biner pvmfw.
- ABL menambahkan node wilayah memori cadangan
linux,pkvm-guest-firmware-memoryke DT, yang menjelaskan lokasi dan ukuran biner pvmfw serta rahasia yang diperolehnya di langkah sebelumnya. - ABL menyerahkan kontrol langsung ke Linux dan Linux melakukan inisialisasi pKVM.
- pKVM membatalkan pemetaan region memori pvmfw dari tabel halaman tahap 2 host dan melindunginya dari host (dan tamu) selama waktu aktif 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 lain) 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 direservasi dan merupakan bagian dari ABI hypervisor-pvmfw.
Saat pVM dijalankan, hypervisor pertama-tama menyerahkan kontrol vCPU utama
ke pvmfw. Firmware mengharapkan crosvm telah memuat kernel yang ditandatangani 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,
akan menghasilkan hierarki perangkat tepercaya dari FDT yang diterima, menghapus 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 secret pvmfw untuk memastikan bahwa, setelah mulai ulang, secret disediakan ke instance yang benar.