Микродроид

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

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

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

Функции

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

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

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

• API-интерфейсы Android Java в пакетах android.\*

• SystemServer и Зигота

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

• HAL-ы

Архитектура микродроида

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

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

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

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

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

Последовательность загрузки Microdroid происходит после загрузки устройства . Загрузка устройства обсуждается в разделе Прошивка pVM документа Архитектура . На рисунке 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. Затем служба менеджера взаимодействует с VirtualizationService Android с помощью Binder RPC, чтобы сообщать о важных событиях, таких как сбой или выключение, и принимать запросы, такие как завершение pVM. Служба менеджера считывает местоположение основного двоичного файла из файла конфигурации APK и выполняет его.

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

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

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

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

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

Управление ключами

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

Связующее RPC

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

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

,

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

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

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

Функции

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

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

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

• API-интерфейсы Android Java в пакетах android.\*

• SystemServer и Зигота

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

• HAL-ы

Архитектура микродроида

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

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

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

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

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

Последовательность загрузки Microdroid происходит после загрузки устройства . Загрузка устройства обсуждается в разделе Прошивка pVM документа Архитектура . На рисунке 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. Затем служба менеджера взаимодействует с VirtualizationService Android с помощью Binder RPC, чтобы сообщать о важных событиях, таких как сбой или выключение, и принимать запросы, такие как завершение pVM. Служба менеджера считывает местоположение основного двоичного файла из файла конфигурации APK и выполняет его.

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

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

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

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

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

Управление ключами

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

Связующее RPC

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

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