Android предоставляет эталонную реализацию всех компонентов, необходимых для реализации платформы виртуализации Android. В настоящее время эта реализация ограничена ARM64. На этой странице объясняется архитектура платформы.
Фон
Архитектура Arm допускает до четырех уровней исключений, при этом уровень исключения 0 (EL0) является наименее привилегированным, а уровень исключения 3 (EL3) — максимальным. Большая часть кодовой базы Android (все компоненты пользовательского пространства) работает на EL0. Остальная часть того, что обычно называют «Android», — это ядро Linux, работающее на уровне EL1.
Уровень EL2 позволяет внедрить гипервизор, который позволяет изолировать память и устройства в отдельных pVM на уровне EL1/EL0 с строгими гарантиями конфиденциальности и целостности.
Гипервизор
Защищенная виртуальная машина на основе ядра (pKVM) построена на основе гипервизора Linux KVM , который был расширен за счет возможности ограничивать доступ к полезным нагрузкам, выполняемым на гостевых виртуальных машинах, помеченных как «защищенные» во время создания.
KVM/arm64 поддерживает различные режимы выполнения в зависимости от доступности определенных функций ЦП, а именно расширений хоста виртуализации (VHE) (ARMv8.1 и более поздних версий). В одном из этих режимов, широко известном как режим без VHE, код гипервизора отделяется от образа ядра во время загрузки и устанавливается в EL2, тогда как само ядро работает в EL1. Компонент EL2 KVM является частью кодовой базы Linux, но представляет собой небольшой компонент, отвечающий за переключение между несколькими EL1. Компонент гипервизора скомпилирован с Linux, но находится в отдельном выделенном разделе памяти образа vmlinux . pKVM использует эту конструкцию, расширяя код гипервизора новыми функциями, позволяющими налагать ограничения на ядро хоста Android и пользовательское пространство, а также ограничивать доступ хоста к гостевой памяти и гипервизору.
Модули поставщиков pKVM
Модуль поставщика pKVM — это аппаратный модуль, содержащий специфичные для устройства функции, такие как драйверы блока управления памятью ввода-вывода (IOMMU). Эти модули позволяют переносить функции безопасности, требующие доступа уровня исключения 2 (EL2), в pKVM.
Чтобы узнать, как реализовать и загрузить модуль поставщика pKVM, обратитесь к разделу «Реализация модуля поставщика pKVM» .
Процедура загрузки
На следующем рисунке показана процедура загрузки pKVM:
- Загрузчик входит в общее ядро на уровне EL2.
- Общее ядро обнаруживает, что оно работает на уровне EL2, и лишает себя права доступа к EL1, в то время как pKVM и его модули продолжают работать на уровне EL2. Кроме того, в это время загружаются модули поставщика pKVM.
- Обычное ядро загружается нормально, загружая все необходимые драйверы устройств, пока не достигнет пользовательского пространства. На данный момент pKVM уже установлен и обрабатывает таблицы страниц этапа 2.
Процедура загрузки доверяет загрузчику поддерживать целостность образа ядра только во время ранней загрузки. Когда ядро лишено привилегий, оно больше не считается доверенным гипервизором, который затем несет ответственность за свою защиту, даже если ядро скомпрометировано.
Наличие ядра Android и гипервизора в одном двоичном образе обеспечивает очень тесно связанный интерфейс связи между ними. Такая тесная связь гарантирует атомарные обновления двух компонентов, что позволяет избежать необходимости поддерживать стабильность интерфейса между ними и обеспечивает большую гибкость без ущерба для долговременной ремонтопригодности. Тесная связь также позволяет оптимизировать производительность, когда оба компонента могут взаимодействовать, не влияя на гарантии безопасности, предоставляемые гипервизором.
Более того, внедрение GKI в экосистему Android автоматически позволяет развертывать гипервизор pKVM на устройствах Android в том же двоичном виде, что и ядро.
Защита доступа к памяти процессора
Архитектура Arm определяет блок управления памятью (MMU), разделенный на два независимых этапа, оба из которых могут использоваться для реализации трансляции адресов и контроля доступа к различным частям памяти. MMU этапа 1 управляется EL1 и обеспечивает первый уровень трансляции адресов. MMU этапа 1 используется Linux для управления виртуальным адресным пространством, предоставляемым каждому процессу пользовательского пространства, а также его собственному виртуальному адресному пространству.
MMU этапа 2 управляется EL2 и позволяет применить вторую трансляцию адреса к выходному адресу MMU этапа 1, в результате чего получается физический адрес (PA). Трансляция этапа 2 может использоваться гипервизорами для управления и преобразования доступа к памяти со всех гостевых виртуальных машин. Как показано на рисунке 2, когда включены оба этапа трансляции, выходной адрес этапа 1 называется промежуточным физическим адресом (IPA). Примечание. Виртуальный адрес (VA) транслируется в IPA, а затем в PA.
Исторически сложилось так, что KVM работает с включенной трансляцией этапа 2 при работе гостей и с отключением этапа 2 при работе ядра Linux хоста. Эта архитектура позволяет доступу к памяти из MMU этапа 1 хоста проходить через MMU этапа 2, что обеспечивает неограниченный доступ хоста к страницам гостевой памяти. С другой стороны, pKVM обеспечивает защиту второго уровня даже в контексте хоста и возлагает ответственность за защиту страниц гостевой памяти на гипервизор, а не на хост.
KVM в полной мере использует трансляцию адресов на этапе 2 для реализации сложных сопоставлений IPA/PA для гостей, что создает для гостей иллюзию непрерывной памяти, несмотря на физическую фрагментацию. Однако использование MMU этапа 2 для хоста ограничивается только контролем доступа. Стадия хоста 2 сопоставлена с идентификаторами, гарантируя, что непрерывная память в пространстве IPA хоста является смежной в пространстве PA. Эта архитектура позволяет использовать большие сопоставления в таблице страниц и, следовательно, снижает нагрузку на резервный буфер трансляции (TLB). Поскольку сопоставление идентификаторов может быть проиндексировано PA, этап хоста 2 также используется для отслеживания владения страницей непосредственно в таблице страниц.
Защита прямого доступа к памяти (DMA)
Как описано ранее, отключение гостевых страниц хоста Linux в таблицах страниц ЦП является необходимым, но недостаточным шагом для защиты гостевой памяти. pKVM также необходимо защищать от доступа к памяти со стороны устройств с поддержкой DMA, находящихся под контролем ядра хоста, а также от возможности атаки DMA, инициированной злонамеренным хостом. Чтобы предотвратить доступ такого устройства к гостевой памяти, pKVM требует аппаратного обеспечения блока управления памятью ввода-вывода (IOMMU) для каждого устройства с поддержкой DMA в системе, как показано на рисунке 3.
Как минимум, аппаратное обеспечение IOMMU предоставляет средства предоставления и отзыва доступа устройства к физической памяти на чтение/запись на уровне детализации страниц. Однако это оборудование IOMMU ограничивает использование устройств в pVM, поскольку они предполагают этап 2 с сопоставлением идентификаторов.
Чтобы обеспечить изоляцию между виртуальными машинами, транзакции памяти, генерируемые от имени разных объектов, должны быть различимы IOMMU, чтобы для трансляции можно было использовать соответствующий набор таблиц страниц.
Кроме того, сокращение объема кода, специфичного для SoC, на EL2 является ключевой стратегией сокращения общей базы доверенных вычислений (TCB) pKVM и противоречит включению драйверов IOMMU в гипервизор. Чтобы смягчить эту проблему, хост EL1 отвечает за вспомогательные задачи управления IOMMU, такие как управление питанием, инициализация и, при необходимости, обработка прерываний.
Однако предоставление хосту контроля над состоянием устройства предъявляет дополнительные требования к программному интерфейсу оборудования IOMMU, чтобы гарантировать, что проверки разрешений нельзя будет обойти другими способами, например, после перезагрузки устройства.
Стандартным и хорошо поддерживаемым IOMMU для устройств Arm, который делает возможной как изоляцию, так и прямое назначение, является архитектура Arm System Memory Management Unit (SMMU). Эта архитектура является рекомендуемым эталонным решением.
Владение памятью
Во время загрузки предполагается, что вся память, не относящаяся к гипервизору, принадлежит хосту и отслеживается как таковая гипервизором. Когда создается pVM, хост жертвует страницы памяти, чтобы позволить ему загружаться, а гипервизор передает право владения этими страницами от хоста к pVM. Таким образом, гипервизор вводит ограничения контроля доступа в таблицу страниц второго уровня хоста, чтобы предотвратить повторный доступ к страницам, обеспечивая конфиденциальность гостю.
Общение между хозяином и гостями становится возможным благодаря контролируемому совместному использованию памяти между ними. Гостям разрешено делиться некоторыми из своих страниц с хостом с помощью гипервызова, который инструктирует гипервизор пересопоставить эти страницы в таблице страниц второго этапа хоста. Аналогично, связь хоста с TrustZone становится возможной благодаря операциям совместного использования и/или предоставления памяти, все из которых тщательно отслеживаются и контролируются pKVM с использованием спецификации Firmware Framework for Arm (FF-A) .
Поскольку требования к памяти pVM могут со временем меняться, предоставляется гипервызов, который позволяет вернуть право владения указанными страницами, принадлежащими вызывающей стороне, обратно хосту. На практике этот гипервызов используется с протоколом воздушного шара virtio, чтобы позволить VMM запрашивать обратно память у pVM, а также чтобы pVM уведомляла VMM об освобожденных страницах контролируемым образом.
Гипервизор отвечает за отслеживание владения всеми страницами памяти в системе и за то, используются ли они совместно или предоставляются в аренду другим объектам. Большая часть этого отслеживания состояния выполняется с использованием метаданных, прикрепленных к таблицам страниц узла и гостя на этапе 2, с использованием зарезервированных битов в записях таблицы страниц (PTE), которые, как следует из их названия, зарезервированы для использования программным обеспечением.
Хост должен гарантировать, что он не пытается получить доступ к страницам, которые гипервизор сделал недоступными. Незаконный доступ к хосту приводит к тому, что гипервизор вводит синхронное исключение в хост, что может привести либо к тому, что ответственная задача пользовательского пространства получит сигнал SEGV, либо к сбою ядра хоста. Чтобы предотвратить случайный доступ, страницы, переданные гостям, не подлежат обмену или объединению ядром хоста.
Обработка прерываний и таймеры
Прерывания являются важной частью взаимодействия гостя с устройствами и связи между процессорами, где межпроцессорные прерывания (IPI) являются основным механизмом связи. Модель KVM заключается в делегировании всего управления виртуальными прерываниями хосту в EL1, который для этой цели ведет себя как недоверенная часть гипервизора.
pKVM предлагает полную эмуляцию универсального контроллера прерываний версии 3 (GICv3), основанную на существующем коде KVM. Таймер и IPI обрабатываются как часть этого ненадежного кода эмуляции.
Поддержка GICv3
Интерфейс между EL1 и EL2 должен обеспечивать видимость полного состояния прерывания для хоста EL1, включая копии регистров гипервизора, связанных с прерываниями. Эта видимость обычно достигается с помощью областей общей памяти, по одной на каждый виртуальный ЦП (vCPU).
Код поддержки системного регистра во время выполнения можно упростить, чтобы поддерживать только перехват регистра программно-генерируемых прерываний (SGIR) и регистра деактивации прерываний (DIR). Архитектура требует, чтобы эти регистры всегда соответствовали EL2, в то время как другие ловушки до сих пор были полезны только для устранения ошибок. Все остальное решается аппаратно.
Со стороны MMIO все эмулируется на EL1, повторно используя всю текущую инфраструктуру KVM. Наконец, ожидание прерывания (WFI) всегда передается на EL1, поскольку это один из основных примитивов планирования, используемых KVM.
Поддержка таймера
Значение компаратора для виртуального таймера должно быть предоставлено EL1 на каждом перехватывающем WFI, чтобы EL1 мог вводить прерывания таймера, пока виртуальный ЦП заблокирован. Физический таймер полностью эмулируется, и все прерывания передаются на EL1.
Обработка MMIO
Для связи с монитором виртуальной машины (VMM) и выполнения эмуляции GIC ловушки MMIO должны быть ретранслированы обратно на хост в EL1 для дальнейшей сортировки. pKVM требует следующего:
- IPA и размер доступа
- Данные в случае записи
- Порядок байтов процессора в момент захвата
Кроме того, ловушки с регистром общего назначения (GPR) в качестве источника/назначения передаются с использованием абстрактного псевдорегистра передачи.
Гостевые интерфейсы
Гость может общаться с защищенным гостем, используя комбинацию гипервызовов и доступа к памяти к захваченным областям. Гипервызовы предоставляются в соответствии со стандартом SMCCC , при этом диапазон зарезервирован для распределения поставщиком KVM. Следующие гипервызовы имеют особое значение для гостей pKVM.
Общие гипервызовы
- PSCI предоставляет гостю стандартный механизм управления жизненным циклом своих виртуальных ЦП, включая подключение к сети, автономный режим и завершение работы системы.
- TRNG предоставляет гостю стандартный механизм запроса энтропии у pKVM, который передает вызов на EL3. Этот механизм особенно полезен, когда хосту нельзя доверить виртуализацию аппаратного генератора случайных чисел (ГСЧ).
Гипервызовы pKVM
- Разделение памяти с хостом. Вся гостевая память изначально недоступна хосту, но доступ к хосту необходим для связи с общей памятью и для паравиртуализированных устройств, которые полагаются на общие буферы. Гипервызовы для совместного использования и отмены совместного использования страниц с хостом позволяют гостю точно решать, какие части памяти доступны остальной части Android без необходимости рукопожатия.
- Освобождение памяти хосту. Вся гостевая память обычно принадлежит гостю, пока она не будет уничтожена. Это состояние может быть недостаточным для долгоживущих виртуальных машин, требования к памяти которых меняются со временем. Гипервызов
relinquishпозволяет гостю явно передать право собственности на страницы обратно хосту, не требуя завершения гостевого доступа. - Перехват доступа к памяти хосту. Традиционно, если гость KVM обращается к адресу, который не соответствует допустимой области памяти, поток виртуального ЦП выходит на хост, и доступ обычно используется для MMIO и эмулируется VMM в пространстве пользователя. Чтобы облегчить эту обработку, pKVM должен сообщать подробности о сбойной инструкции, такие как ее адрес, параметры регистра и, возможно, их содержимое, обратно на хост, что может непреднамеренно раскрыть конфиденциальные данные защищенного гостя, если ловушка не была ожидаема. pKVM решает эту проблему, рассматривая эти ошибки как фатальные, если только гость ранее не выполнил гипервызов для идентификации сбойного диапазона IPA как диапазона, для которого разрешено обращение к хосту. Это решение называется защитой MMIO .
Виртуальное устройство ввода-вывода (virtio)
Virtio — популярный, портативный и зрелый стандарт для реализации паравиртуализированных устройств и взаимодействия с ними. Большинство устройств, доступных для защищенных гостей, реализованы с использованием virtio. Virtio также лежит в основе реализации vsock, используемой для связи между защищенным гостем и остальной частью Android.
Устройства Virtio обычно реализуются в пользовательском пространстве хоста с помощью VMM, который перехватывает доступ к памяти от гостя к интерфейсу MMIO устройства Virtio и эмулирует ожидаемое поведение. Доступ к MMIO является относительно дорогим, поскольку каждый доступ к устройству требует обратного пути к VMM и обратно, поэтому большая часть фактической передачи данных между устройством и гостем происходит с использованием набора виртуальных очередей в памяти. Ключевое предположение virtio заключается в том, что хост может произвольно обращаться к гостевой памяти. Это предположение очевидно при проектировании очереди виртуализации, которая может содержать указатели на буферы в гостевой системе, к которым эмуляция устройства должна иметь прямой доступ.
Хотя ранее описанные гипервызовы совместного использования памяти могут использоваться для совместного использования буферов данных virtio от гостя к хосту, это совместное использование обязательно выполняется с детализацией страницы и может в конечном итоге раскрыть больше данных, чем требуется, если размер буфера меньше размера страницы. . Вместо этого гость настраивается на выделение как виртуальных очередей, так и соответствующих им буферов данных из фиксированного окна общей памяти, при этом данные копируются (передаются) в окно и из него по мере необходимости.
Взаимодействие с TrustZone
Хотя гости не могут напрямую взаимодействовать с TrustZone, хост все равно должен иметь возможность отправлять вызовы SMC в безопасный мир. Эти вызовы могут указывать физически адресуемые буферы памяти, недоступные хосту. Поскольку защищенное программное обеспечение обычно не знает о доступности буфера, злонамеренный хост может использовать этот буфер для выполнения атаки с запутанным заместителем (аналогично атаке DMA). Чтобы предотвратить такие атаки, pKVM перехватывает все вызовы SMC хоста на EL2 и действует как прокси-сервер между хостом и безопасным монитором на EL3.
Вызовы PSCI от хоста перенаправляются на прошивку EL3 с минимальными изменениями. В частности, точка входа для ЦП, подключающегося к сети или возобновляющего режим ожидания, перезаписывается таким образом, что таблица страниц этапа 2 устанавливается в EL2 перед возвратом на хост в EL1. Во время загрузки эта защита обеспечивается pKVM.
Эта архитектура основана на SoC, поддерживающем PSCI, предпочтительно за счет использования актуальной версии TF-A в качестве прошивки EL3.
Firmware Framework for Arm (FF-A) стандартизирует взаимодействие между обычным и безопасным мирами, особенно при наличии безопасного гипервизора. Основная часть спецификации определяет механизм совместного использования памяти с безопасным миром, используя как общий формат сообщений, так и четко определенную модель разрешений для базовых страниц. pKVM проксирует сообщения FF-A, чтобы гарантировать, что хост не пытается использовать память совместно с защищенной стороной, для которой у него нет достаточных разрешений.
Эта архитектура опирается на программное обеспечение безопасного мира, обеспечивающее модель доступа к памяти, чтобы гарантировать, что доверенные приложения и любое другое программное обеспечение, работающее в безопасном мире, могут получить доступ к памяти, только если она либо принадлежит исключительно безопасному миру, либо была явно разделена с ним с помощью FF. -А. В системе с S-EL2 обеспечение модели доступа к памяти должно выполняться ядром Secure Partition Manager (SPMC), таким как Hafnium , которое поддерживает таблицы страниц этапа 2 для безопасного мира. В системе без S-EL2 TEE может вместо этого реализовать модель доступа к памяти через свои таблицы страниц этапа 1.
Если вызов SMC на EL2 не является вызовом PSCI или сообщением, определенным FF-A, необработанные SMC перенаправляются на EL3. Предполагается, что защищенная прошивка (обязательно доверенная) может безопасно обрабатывать необработанные SMC, поскольку прошивка понимает меры предосторожности, необходимые для поддержания изоляции pVM.
Монитор виртуальной машины
crosvm — это монитор виртуальных машин (VMM), который запускает виртуальные машины через KVM-интерфейс Linux. Что делает crosvm уникальным, так это его внимание к безопасности за счет использования языка программирования Rust и «песочницы» вокруг виртуальных устройств для защиты ядра хоста. Подробнее о crosvm смотрите в его официальной документации здесь .
Дескрипторы файлов и ioctls
KVM предоставляет символьное устройство /dev/kvm пользовательскому пространству с помощью ioctls, составляющих API KVM. ioctls относятся к следующим категориям:
- Системные ioctls запрашивают и устанавливают глобальные атрибуты, которые влияют на всю подсистему KVM, и создают pVM.
- ioctls виртуальной машины запрашивает и устанавливает атрибуты, которые создают виртуальные процессоры (vCPU) и устройства и влияют на всю pVM, например, включая структуру памяти и количество виртуальных процессоров (vCPU) и устройств.
- ioctls vCPU запрашивает и устанавливает атрибуты, управляющие работой одного виртуального процессора.
- ioctls устройства запрашивает и устанавливает атрибуты, управляющие работой одного виртуального устройства.
Каждый процесс crosvm запускает ровно один экземпляр виртуальной машины. Этот процесс использует системный ioctl KVM_CREATE_VM для создания дескриптора файла VM, который можно использовать для выдачи ioctl pVM. ioctl KVM_CREATE_VCPU или KVM_CREATE_DEVICE на VM FD создает виртуальный ЦП/устройство и возвращает дескриптор файла, указывающий на новый ресурс. ioctl на виртуальном ЦП или FD устройства можно использовать для управления устройством, созданным с помощью ioctl на FD VM. Для виртуальных ЦП это включает в себя важную задачу запуска гостевого кода.
Внутренне crosvm регистрирует файловые дескрипторы виртуальной машины в ядре, используя интерфейс epoll запускаемый по краям. Затем ядро уведомляет crosvm всякий раз, когда в любом из файловых дескрипторов ожидается новое событие.
pKVM добавляет новую возможность KVM_CAP_ARM_PROTECTED_VM , которую можно использовать для получения информации о среде pVM и настройки защищенного режима для виртуальной машины. crosvm использует это во время создания pVM, если передан флаг --protected-vm , для запроса и резервирования соответствующего объема памяти для прошивки pVM, а затем для включения защищенного режима.
Распределение памяти
Одной из основных обязанностей VMM является выделение памяти виртуальной машины и управление ее структурой. crosvm генерирует фиксированную структуру памяти, подробно описанную в таблице ниже.
| ФДТ в обычном режиме | PHYS_MEMORY_END - 0x200000 |
| Свободное место | ... |
| Рамдиск | ALIGN_UP(KERNEL_END, 0x1000000) |
| Ядро | 0x80080000 |
| загрузчик | 0x80200000 |
| FDT в режиме BIOS | 0x80000000 |
| База физической памяти | 0x80000000 |
| прошивка ПВМ | 0x7FE00000 |
| Память устройства | 0x10000 - 0x40000000 |
Физическая память выделяется с помощью mmap , и эта память передается виртуальной машине для заполнения ее областей памяти, называемых memslots , с помощью ioctl KVM_SET_USER_MEMORY_REGION . Таким образом, вся гостевая память pVM приписывается экземпляру crosvm, который ею управляет, и может привести к остановке процесса (завершению виртуальной машины), если на хосте начинает заканчиваться свободная память. Когда виртуальная машина останавливается, память автоматически очищается гипервизором и возвращается в ядро хоста.
При обычном KVM VMM сохраняет доступ ко всей гостевой памяти. При использовании pKVM гостевая память не отображается в физическом адресном пространстве хоста, когда она передается гостю. Единственным исключением является память, явно предоставленная гостем, например, для устройств Virtio.
Регионы MMIO в адресном пространстве гостя остаются несопоставленными. Доступ гостя к этим областям блокируется и приводит к событию ввода-вывода на VM FD. Этот механизм используется для реализации виртуальных устройств. В защищенном режиме гость должен подтвердить, что область его адресного пространства используется для MMIO с помощью гипервызова, чтобы снизить риск случайной утечки информации.
Планирование
Каждый виртуальный процессор представлен потоком POSIX и запланирован планировщиком хоста Linux. Поток вызывает ioctl KVM_RUN на виртуальном ЦП FD, в результате чего гипервизор переключается на контекст гостевого виртуального ЦП. Планировщик хоста учитывает время, проведенное в гостевом контексте, как время, использованное соответствующим потоком виртуального ЦП. KVM_RUN возвращается, когда происходит событие, которое должно быть обработано VMM, например ввод-вывод, завершение прерывания или остановка виртуального ЦП. VMM обрабатывает событие и снова вызывает KVM_RUN .
Во время KVM_RUN поток остается вытесняемым планировщиком узла, за исключением выполнения кода гипервизора EL2, который не является вытесняемым. Сама гостевая pVM не имеет механизма контроля такого поведения.
Поскольку все потоки виртуальных ЦП планируются так же, как и любые другие задачи пользовательского пространства, на них распространяются все стандартные механизмы QoS. В частности, каждый поток виртуальных ЦП можно привязать к физическим ЦП, поместить в наборы процессоров, увеличить или ограничить с помощью ограничения использования, изменить политику приоритетов/планирования и многое другое.
Виртуальные устройства
crosvm поддерживает ряд устройств, в том числе следующие:
- virtio-blk для составных образов дисков, только чтение или чтение-запись
- vhost-vsock для связи с хостом
- virtio-pci как транспорт virtio
- pl030 часы реального времени (RTC)
- 16550a UART для последовательной связи
прошивка ПВМ
Прошивка pVM (pvmfw) — это первый код, выполняемый pVM, аналогичный загрузочному ПЗУ физического устройства. Основная цель pvmfw — обеспечить безопасную загрузку и получить уникальный секрет pVM. pvmfw не ограничивается использованием какой-либо конкретной ОС, например Microdroid , если ОС поддерживается crosvm и правильно подписана.
Бинарный файл pvmfw хранится в одноименном флэш-разделе и обновляется с помощью OTA .
Загрузка устройства
В процедуру загрузки устройства с поддержкой pKVM добавляется следующая последовательность шагов:
- Загрузчик Android (ABL) загружает pvmfw из своего раздела в память и проверяет образ.
- ABL получает секреты механизма композиции идентификаторов устройств (DICE) (составные идентификаторы устройств (CDI) и цепочку сертификатов DICE) из корня доверия.
- ABL получает необходимые CDI для pvmfw и добавляет их в двоичный файл pvmfw.
- ABL добавляет в DT узел зарезервированной области памяти
linux,pkvm-guest-firmware-memory, описывающий расположение и размер двоичного файла pvmfw, а также секреты, полученные им на предыдущем шаге. - ABL передает управление Linux, а Linux инициализирует pKVM.
- pKVM отменяет отображение области памяти pvmfw из таблиц страниц второго уровня хоста и защищает ее от хоста (и гостей) на протяжении всего времени безотказной работы устройства.
После загрузки устройства Microdroid загружается в соответствии с инструкциями, описанными в разделе «Последовательность загрузки» документа Microdroid .
пВМ-загрузка
При создании pVM crosvm (или другой VMM) должен создать достаточно большой слот памяти, чтобы гипервизор мог заполнить его образом pvmfw. VMM также ограничен списком регистров, начальное значение которых он может установить (x0–x14 для основного виртуального ЦП, ни одного для вторичного виртуального ЦП). Остальные регистры зарезервированы и являются частью ABI гипервизора-pvmfw.
При запуске pVM гипервизор сначала передает управление основным виртуальным ЦП pvmfw. Прошивка ожидает, что crosvm загрузит подписанное AVB ядро, которое может быть загрузчиком или любым другим образом, а также беззнаковый FDT в память по известным смещениям. pvmfw проверяет подпись AVB и в случае успеха генерирует дерево доверенных устройств на основе полученного FDT, стирает его секреты из памяти и переходит к точке входа полезной нагрузки. Если один из шагов проверки не удался, встроенное ПО выдает гипервызов PSCI SYSTEM_RESET .
Между загрузками информация об экземпляре pVM сохраняется в разделе (устройство virtio-blk) и шифруется с помощью секрета pvmfw, чтобы гарантировать, что после перезагрузки секрет будет передан правильному экземпляру.