Microdroid adalah OS Android mini yang berjalan di pVM. Anda tidak perlu menggunakan Microdroid, Anda dapat memulai VM dengan OS apa pun. Namun, kasus penggunaan utama untuk pVM tidak menjalankan OS mandiri, tetapi menawarkan lingkungan eksekusi terisolasi untuk menjalankan sebagian aplikasi dengan jaminan kerahasiaan dan integritas yang lebih kuat daripada yang dapat diberikan Android.
Dengan sistem operasi tradisional, memberikan kerahasiaan dan integritas yang kuat memerlukan cukup banyak pekerjaan (sering kali diduplikasi) karena sistem operasi tradisional tidak sesuai dengan arsitektur Android yang menyeluruh. Misalnya, dengan arsitektur Android standar, developer harus menerapkan cara memuat dan menjalankan bagian aplikasi mereka di pVM dengan aman, dan payload dibuat berdasarkan glibc. Aplikasi Android menggunakan Bionic, komunikasi memerlukan protokol kustom melalui vsock, dan proses debug menggunakan adb cukup sulit.
Microdroid mengisi kekurangan ini dengan menyediakan image OS siap pakai yang dirancang agar developer tidak perlu melakukan upaya besar untuk memindahkan sebagian aplikasi mereka ke dalam pVM. Kode native dibuat berdasarkan Bionic, komunikasi terjadi melalui Binder, dan memungkinkan impor APEX dari Android host serta mengekspos subkumpulan Android API, seperti keystore untuk operasi kriptografis dengan kunci yang didukung hardware. Secara keseluruhan, developer akan menemukan Microdroid sebagai lingkungan yang sudah dikenal dengan alat yang sudah mereka gunakan di Android OS versi lengkap.
Fitur
Microdroid adalah versi Android yang dihilangkan dengan beberapa komponen tambahan yang khusus untuk pVM. Microdroid mendukung:
- Subkumpulan API NDK (semua API untuk implementasi libc dan Bionic Android disediakan)
- Fitur proses debug, seperti adb, logcat, tombstone, dan gdb
- Booting Terverifikasi dan SELinux
- Memuat dan mengeksekusi biner, bersama dengan library bersama, yang disematkan dalam APK
- RPC Binder melalui vsock dan pertukaran file dengan pemeriksaan integritas implisit
- Pemuatan APEX
Microdroid tidak mendukung:
Android Java API dalam paket
android.\*
SystemServer dan Zygote
Grafis/UI
HAL
Arsitektur microdroid
Microdroid mirip dengan Cuttlefish karena keduanya memiliki arsitektur yang mirip dengan Android standar. Microdroid terdiri dari image partisi berikut yang dikelompokkan dalam image disk gabungan:
bootloader
- Memverifikasi dan memulai kernel.boot.img
- Berisi kernel dan ramdisk init.vendor_boot.img
- Berisi modul kernel khusus VM, seperti virtio.super.img
- Terdiri dari partisi logis sistem dan vendor.vbmeta.img
- Berisi metadata booting terverifikasi.
Image partisi dikirim dalam Virtualization APEX dan dikemas dalam
image disk komposit oleh VirtualizationService
. Selain image disk komposit OS utama, VirtualizationService
bertanggung jawab untuk membuat
partisi lain ini:
payload
- Kumpulan partisi yang didukung oleh APEX dan APK Androidinstance
- Partisi terenkripsi untuk mempertahankan data booting yang diverifikasi per instance, seperti salt per instance, kunci publik APEX tepercaya, dan penghitung rollback
Urutan booting
Urutan booting Microdroid terjadi setelah Booting perangkat. Proses booting perangkat dibahas di bagian Firmware pVM dalam dokumen Arsitektur. Gambar 1 menunjukkan langkah-langkah yang terjadi selama urutan booting Microdroid:
Berikut penjelasan langkah-langkahnya:
Bootloader dimuat ke dalam memori oleh crosvm dan pvmfw mulai dieksekusi. Sebelum beralih ke bootloader, pvmfw melakukan dua tugas:
- Memverifikasi bootloader untuk memeriksa apakah berasal dari sumber tepercaya (Google atau OEM).
- Memastikan bahwa bootloader yang sama digunakan secara konsisten di beberapa booting pVM yang sama melalui penggunaan image instance. Secara khusus, pVM awalnya di-booting dengan image instance kosong. pvmfw menyimpan identitas bootloader dalam image instance dan mengenkripsinya. Jadi, saat berikutnya pVM di-booting dengan image instance yang sama, pvmfw akan mendekripsi identitas yang disimpan dari image instance dan memverifikasi bahwa identitas tersebut sama dengan yang disimpan sebelumnya. Jika identitasnya berbeda, pvmfw akan menolak untuk melakukan booting.
Bootloader kemudian mem-booting Microdroid.
Bootloader mengakses disk instance. Serupa dengan pvmfw, bootloader memiliki instance disk drive dengan informasi tentang image partisi yang digunakan dalam instance ini selama booting sebelumnya, termasuk kunci publik.
Bootloader memverifikasi vbmeta dan partisi berantai, seperti
boot
dansuper
, dan, jika berhasil, akan memperoleh secret pVM tahap berikutnya. Kemudian, Microdroid menyerahkan kontrol ke kernel.Karena partisi super telah diverifikasi oleh bootloader (langkah 3), kernel memasang partisi super tanpa syarat. Seperti halnya Android versi lengkap, partisi super terdiri dari beberapa partisi logis yang dipasang melalui dm-verity. Kontrol kemudian diteruskan ke proses
init
, yang memulai berbagai layanan native. Skripinit.rc
mirip dengan skrip Android lengkap, tetapi disesuaikan dengan kebutuhan Microdroid.Proses
init
memulai pengelola Microdroid, yang mengakses image instance. Layanan pengelola Microdroid mendekripsi image menggunakan kunci yang diteruskan dari tahap sebelumnya dan membaca kunci publik serta penghitung rollback APK dan APEX klien yang dipercaya pVM ini. Informasi ini nantinya digunakan olehzipfuse
danapexd
saat masing-masing memasang APK klien dan APEX yang diminta.Layanan pengelola Microdroid memulai
apexd
.apexd
memasang APEX di direktori/apex/<name>
. Satu-satunya perbedaan antara cara Android dan Microdroid memasang APEX adalah di Microdroid, file APEX berasal dari perangkat blok virtual (/dev/vdc1
, …), bukan dari file reguler (/system/apex/*.apex
).zipfuse
adalah sistem file FUSE Microdroid.zipfuse
memasang APK klien, yang pada dasarnya adalah file Zip sebagai sistem file. Di bawahnya, file APK diteruskan sebagai perangkat blok virtual oleh pVM dengan dm-verity, sama seperti APEX. APK berisi file konfigurasi dengan daftar APEX yang telah diminta oleh developer aplikasi untuk instance pVM ini. Daftar ini digunakan olehapexd
saat mengaktifkan APEX.Alur booting kembali ke layanan pengelola Microdroid. Layanan pengelola kemudian berkomunikasi dengan
VirtualizationService
Android menggunakan Binder RPC agar dapat melaporkan peristiwa penting seperti error atau penonaktifan, dan menerima permintaan seperti penghentian pVM. Layanan pengelola membaca lokasi biner utama dari file konfigurasi APK dan mengeksekusinya.
Pertukaran file (AuthFS)
Komponen Android biasanya menggunakan file untuk input, output, dan status
serta meneruskannya sebagai deskripsi file (jenis ParcelFileDescriptor
di
AIDL) dengan akses yang dikontrol oleh kernel Android. AuthFS memfasilitasi fungsi serupa untuk bertukar file antara endpoint yang tidak saling percaya di seluruh batas pVM.
Pada dasarnya, AuthFS adalah sistem file jarak jauh dengan pemeriksaan integritas transparan
pada setiap operasi akses, mirip dengan fs-verity
. Pemeriksaan ini memungkinkan
frontend, seperti program pembacaan file yang berjalan di pVM, untuk mendeteksi apakah
backend yang tidak tepercaya, biasanya Android, dirusak dengan konten file.
Untuk bertukar file, backend (fd\_server
) dimulai dengan konfigurasi
per file yang menentukan apakah ini dimaksudkan untuk input (hanya baca) atau output
(baca-tulis). Untuk input, frontend menerapkan bahwa konten cocok dengan hash
yang diketahui, di atas hierarki Merkle untuk verifikasi saat akses. Untuk output, AuthFS
secara internal mempertahankan hierarki hash konten seperti yang diamati dari operasi
menulis dan dapat menerapkan integritas saat data dibaca kembali.
Transpor yang mendasarinya saat ini didasarkan pada Binder RPC, tetapi hal itu mungkin berubah pada masa mendatang untuk mengoptimalkan performa.
Pengelolaan kunci
pVM dilengkapi dengan kunci penyegelan yang stabil dan cocok untuk melindungi data persisten, serta kunci pengesahan yang cocok untuk menghasilkan tanda tangan yang dapat diverifikasi oleh pVM.
RPC Binder
Sebagian besar antarmuka Android dinyatakan dalam AIDL, yang dibuat di atas driver kernel Linux Binder. Untuk mendukung antarmuka antara pVM, protokol Binder telah ditulis ulang agar berfungsi melalui soket, vsock dalam kasus pVM. Beroperasi melalui soket memungkinkan antarmuka AIDL Android yang ada digunakan di lingkungan baru ini.
Untuk menyiapkan koneksi, satu endpoint, seperti payload pVM, membuat
objek RpcServer
, mendaftarkan objek root, dan mulai memproses koneksi
baru. Klien dapat terhubung ke server ini menggunakan objek RpcSession
,
mendapatkan objek Binder
, dan menggunakannya persis seperti objek Binder
digunakan
dengan driver Binder kernel.