Архитектура систем прошивки на базе ARMv8

С момента выпуска в 2011 году архитектура процессора ARMv8 получила достаточно широкое распространение на рынке мобильных устройств. По прогнозам генерального директора ARM Limited, процессоры этого поколения к 2020 году приобретут долю на мировом рынке до 25%. Вполне естественно, что программная поддержка была налажена и развивалась дальше, унаследовав функции и общие характеристики. принципы исторически сложившейся инфраструктуры.

Принципиально иная ситуация наблюдается в серверном сегменте рынка. Серверы на базе X86 уже давно доминируют в этой области, в то время как ARMv8 только находит свой путь (и только в определенных бизнес-сегментах). Новизна этого рынка для ARM и тот факт, что большинство принятых стандартов и спецификаций (прежде всего, ACPI и UEFI) не были адаптированы для систем ARM до недавнего времени, наложили свой отпечаток на развитие инфраструктуры программного обеспечения.

Эта статья посвящена обзору серверных систем и процессоров на базе ARM и не претендует на исчерпывающее описание. Авторы также хотели бы обратить внимание читателя на тот факт, что предоставленные данные могут быстро устареть - достаточно скоро появятся новые процессоры с новыми техническими решениями, которые могут потребовать другого подхода к реализации инфраструктуры программного обеспечения.

Во-первых, следует отметить, что текущие реализации микропрограмм для серверных систем ARMv8 состоят из нескольких относительно независимых компонентов. Это дает ряд преимуществ, таких как возможность использования одних и тех же компонентов во встроенном ПО сервера и встроенных систем, а также относительная независимость вносимых изменений.

Итак, какие модули и компоненты используются в этих системах и каковы их функции? Общая схема загрузки и взаимодействия модулей показана на рис. 1. Процесс начинается с инициализации подсистем, таких как ОЗУ и межпроцессорные интерфейсы. В текущих реализациях это выполняется отдельным модулем в режиме EL3S сразу после включения питания основного процессора. Таким образом, этот компонент системы имеет максимально возможные привилегии. Обычно он не взаимодействует напрямую с ОС.

Рис 1. Загрузка и взаимодействие модулей. (Источник:Аурига)

Позже управление передается следующему компоненту, чаще всего модулю ARM Trusted Firmware (ATF), который выполняется в том же режиме. Управление ATF может быть передано либо непосредственно от загрузчика уровня 0, описанного в предыдущем абзаце, либо косвенно через специальный модуль UEFI, реализующий PEI (инициализацию PreEFI). ATF состоит из нескольких модулей, которые получают управление в разное время.

Модуль запуска BL1 выполняет инициализацию частей платформы, назначенных для режима защищенного процессора. Поскольку системы на базе ARMv8 используют аппаратное разделение для доверенных и ненадежных ресурсов, включая ОЗУ, модуль BL1 подготавливает среду, в которой может выполняться доверенный код. В частности, этот тип инициализации включает конфигурацию контроллеров памяти / кеша (доверенные и недоверенные зоны помечаются посредством программирования регистров в этих устройствах) и маркировку встроенных устройств (энергонезависимые контроллеры памяти). Эта разметка также вводит фильтрацию транзакций DMA на основе типов устройств (доверенные / ненадежные). Учитывая все это, запись / чтение памяти возможны только в / из областей, параметры безопасности которых совпадают с настройками безопасности устройства. Реализация доверенной среды может быть довольно сложной; например, они могут включать в себя отдельную ОС. Однако описание таких реализаций выходит за рамки данной статьи.

Модуль BL1 настраивает таблицу преобразования адресов MMU, а также таблицу обработчиков исключений, где наиболее важным элементом является обработчик исключений для инструкции Secure Monitor Call (SMC). На данный момент обработчик минимален и фактически может передавать управление только изображениям, загруженным в ОЗУ. Во время работы модуль BL1 загружает следующую ступень (BL2) в RAM и передает ей управление. Модуль BL2 работает в режиме EL1S с ограниченными привилегиями. Следовательно, передача управления этому модулю осуществляется с помощью инструкции «ERET».

Назначение модуля BL2 - загрузить остальные модули прошивки (части BL3) и передать им управление. Пониженный уровень привилегий используется, чтобы избежать возможного повреждения кода и данных EL3S, уже находящихся в памяти. Код этих частей выполняется путем вызова кода EL3S, расположенного на этапе BL1, с помощью инструкции SMC.

Третий этап загрузки и инициализации ATF может состоять из трех этапов, но второй этап обычно опускается. Таким образом, фактически осталось только двое. Модуль BL3-1 является частью доверенного кода, доступного для универсального программного обеспечения (ОС и т. Д.) Во время выполнения. Ключевой частью этого модуля является обработчик исключений, вызываемый инструкцией «SMC». В самом модуле есть функции для реализации стандартных вызовов SMC:код, реализующий стандартный интерфейс PSCI (предназначенный для управления всей платформой, например включение / отключение ядер процессора, управление питанием на уровне платформы и перезагрузка), а также обрабатывает поставщик -специфические вызовы (предоставление информации о платформе, управление встроенными устройствами и т. д.).

Как упоминалось выше, наличие модуля BL3-2 не является обязательным; его код (в случае модуля) выполняется в режиме EL1S. Обычно он служит специализированным сервисом / монитором событий, происходящих во время работы платформы (прерывания от определенных таймеров, устройств и т. Д.)

По сути, BL3-3 - это не модуль ATF, а образ прошивки, выполненный в небезопасном режиме. Обычно он берет на себя управление в режиме EL2 и представляет собой образ либо загрузчика, похожего на широко известный U-Boot, либо образ среды UEFI, который является стандартным для серверных систем.

Общая схема инициализации модуля ATF представлена ​​на рис. 2.

Рис. 2. Инициализация модуля ATF. (Источник:Аурига)