Микродроид

Microdroid — это мини-ОС Android, работающая на pVM. Вам не обязательно использовать Microdroid, вы можете запустить ВМ с любой ОС. Однако основные варианты использования pVM — это не автономная ОС, а скорее предложение изолированной среды выполнения для запуска части приложения с более сильными гарантиями конфиденциальности и целостности, чем может предоставить Android.

В традиционных операционных системах обеспечение строгой конфиденциальности и целостности требует значительного объема работы (часто дублируемой), поскольку традиционные операционные системы не вписываются в общую архитектуру Android. Например, в стандартной архитектуре Android разработчикам необходимо реализовать средства безопасной загрузки и выполнения части своего приложения в pVM, а полезная нагрузка создается на основе glibc. Приложение Android использует Bionic, для связи требуется специальный протокол через vsock, а отладка с помощью adb затруднительна.

Microdroid заполняет эти пробелы, предоставляя готовый образ ОС, предназначенный для того, чтобы требовать от разработчиков наименьших усилий для выгрузки части своего приложения в PVM. Собственный код построен на базе Bionic, связь происходит через Binder, он позволяет импортировать APEX из Android и предоставляет подмножество Android API, например хранилище ключей для криптографических операций с аппаратно поддерживаемыми ключами. В целом, разработчики должны найти Microdroid знакомой средой с инструментами, к которым они привыкли в полной версии ОС Android.

Функции

Microdroid — это урезанная версия Android с несколькими дополнительными компонентами, специфичными для pVM. Микродроид поддерживает:

  • Подмножество API-интерфейсов NDK (предоставляются все API-интерфейсы для реализации libc и Bionic в Android)
  • Функции отладки, такие как adb, logcat, tombstone и gdb.
  • Проверенная загрузка и включен SELinux.
  • Загрузка и выполнение двоичного файла вместе с общими библиотеками, встроенными в APK
  • Binder RPC через vsock и обмен файлами с неявной проверкой целостности
  • Загрузка APEX

Микродроид не поддерживает:

  • API Java для Android в пакетах android.\*

  • Системсервер и Зигота

  • Графика/пользовательский интерфейс

  • HAL

Микродроидная архитектура

Microdroid похож на Cuttlefish тем, что оба имеют архитектуру, аналогичную стандартной Android. Microdroid состоит из следующих образов разделов, сгруппированных в составной образ диска:

  • bootloader — проверяет и запускает ядро.
  • boot.img — содержит ядро ​​и инициализирующий виртуальный диск.
  • vendor_boot.img — содержит модули ядра, специфичные для виртуальной машины, такие как virtio.
  • super.img — Состоит из системных и вендорных логических разделов.
  • vbmeta.img — содержит проверенные метаданные загрузки.

Образы разделов поставляются в Virtualization APEX и упаковываются в составной образ диска службой VirtualizationService . Помимо основного образа составного диска ОС, VirtualizationService отвечает за создание следующих разделов:

  • payload — набор разделов, поддерживаемых APEX и APK для Android.
  • instance — зашифрованный раздел для хранения проверенных загрузочных данных для каждого экземпляра, таких как соль для каждого экземпляра, доверенные открытые ключи APEX и счетчики отката.

Последовательность загрузки

Последовательность загрузки Microdroid происходит после загрузки устройства . Загрузка устройства обсуждается в документе «Архитектура» . На рисунке 1 показаны шаги, которые происходят во время загрузки Microdroid:

Безопасный процесс загрузки экземпляра microdroid

Рисунок 1. Безопасный процесс загрузки экземпляра microdroid

Вот объяснение шагов:

  1. Загрузчик загружается в память с помощью crosvm, и pvmfw начинает выполняться. Прежде чем перейти к загрузчику, pvmfw выполняет две задачи:

    • Проверяет загрузчик, чтобы убедиться, что он получен из надежного источника (Google или OEM).
    • Гарантирует, что один и тот же загрузчик последовательно используется при нескольких загрузках одной и той же pVM за счет использования образа экземпляра. В частности, pVM изначально загружается с пустым образом экземпляра. pvmfw сохраняет идентификатор загрузчика в образе экземпляра и шифрует его. Таким образом, в следующий раз, когда pVM загрузится с тем же образом экземпляра, pvmfw расшифровывает сохраненный идентификатор из образа экземпляра и проверяет, что это тот же самый образ, который был сохранен ранее. Если идентификаторы различаются, pvmfw отказывается загружаться.

    Затем загрузчик загружает Microdroid.

  2. Загрузчик обращается к диску экземпляра. Подобно pvmfw, загрузчик имеет диск экземпляра с информацией об образах разделов, использованных в этом экземпляре во время предыдущих загрузок, включая открытый ключ.

  3. Загрузчик проверяет vbmeta и связанные разделы, такие как boot и super , и в случае успеха извлекает секреты pVM следующего этапа. Затем Microdroid передает управление ядру.

  4. Поскольку суперраздел уже проверен загрузчиком (шаг 3), ядро ​​безоговорочно монтирует суперраздел. Как и в полной версии Android, суперраздел состоит из нескольких логических разделов, смонтированных через dm-verity. Затем управление передается процессу init , который запускает различные собственные службы. Сценарий init.rc аналогичен сценарию полноценной версии Android, но адаптирован к потребностям Microdroid.

  5. Процесс init запускает диспетчер Microdroid, который обращается к образу экземпляра. Служба диспетчера Microdroid расшифровывает образ с помощью ключа, переданного на предыдущем этапе, и считывает открытые ключи и счетчики отката клиентских APK и APEX, которым доверяет эта pVM. Эта информация позже используется zipfuse и apexd когда они монтируют клиентский APK и запрашивают APEX соответственно.

  6. Служба диспетчера Microdroid запускает apexd .

  7. apexd монтирует APEX в каталогах /apex/<name> . Единственная разница между тем, как Android и Microdroid монтируют APEX, заключается в том, что в Microdroid файлы APEX поступают из виртуальных блочных устройств ( /dev/vdc1 , …), а не из обычных файлов ( /system/apex/*.apex ).

  8. zipfuse — файловая система FUSE компании Microdroid. zipfuse монтирует клиентский APK, который по сути представляет собой Zip-файл в качестве файловой системы. Ниже файл APK передается pVM как виртуальное блочное устройство с dm-verity, так же, как и APEX. APK-файл содержит файл конфигурации со списком APEX, которые разработчик приложения запросил для этого экземпляра pVM. Список используется apexd при активации APEX.

  9. Поток загрузки возвращается в службу диспетчера Microdroid. Затем служба менеджера связывается с Android VirtualizationService с помощью Binder RPC, чтобы она могла сообщать о важных событиях, таких как сбой или завершение работы, и принимать запросы, такие как завершение работы pVM. Служба менеджера считывает расположение основного двоичного файла из файла конфигурации APK и выполняет его.

Обмен файлами (AuthFS)

Компоненты Android обычно используют файлы для ввода, вывода и состояния и передают их как файловые дескрипторы (тип ParcelFileDescriptor в AIDL) с доступом, контролируемым ядром Android. AuthFS обеспечивает аналогичную функциональность для обмена файлами между взаимно не доверяющими конечными точками через границы pVM.

По сути, AuthFS — это удаленная файловая система с прозрачной проверкой целостности отдельных операций доступа, аналогичная fs-verity . Эти проверки позволяют интерфейсу, например программе чтения файлов, работающей в pVM, обнаружить, не подделал ли ненадежный сервер, обычно Android, содержимое файла.

Для обмена файлами серверная часть ( fd\_server ) запускается с конфигурацией каждого файла, определяющей, предназначен ли он для ввода (только чтение) или вывода (чтение-запись). Для ввода внешний интерфейс обеспечивает соответствие содержимого известному хешу поверх дерева Меркла для проверки при доступе. Для вывода AuthFS внутренне поддерживает хэш-дерево содержимого, наблюдаемое при операциях записи, и может обеспечивать целостность при обратном чтении данных.

Базовый транспорт в настоящее время основан на Binder RPC, однако в будущем это может измениться для оптимизации производительности.

Ключевой менеджмент

PVM снабжены стабильным ключом запечатывания , подходящим для защищенных постоянных данных, и ключом аттестации , подходящим для создания подписей, которые проверяемо создаются PVM.

Связующее РПК

Большинство интерфейсов Android выражены в AIDL , который построен на основе драйвера ядра Binder Linux. Для поддержки интерфейсов между pVM протокол Binder был переписан для работы через сокеты, vsock в случае pVM. Работа через сокеты позволяет использовать существующие интерфейсы AIDL Android в этой новой среде.

Чтобы установить соединение, одна конечная точка, например полезная нагрузка pVM, создает объект RpcServer , регистрирует корневой объект и начинает прослушивать новые соединения. Клиенты могут подключиться к этому серверу с помощью объекта RpcSession , получить объект Binder и использовать его точно так же, как объект Binder используется с драйвером Binder ядра.