Архитектура прошивки ARMv8: Ключевые компоненты и поток загрузки в серверных системах

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

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

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

Текущие реализации прошивки для ARMv8 серверов модульны, предлагая преимущество повторного использования компонентов между серверной и встроенной прошивкой при изоляции изменений. Рисунок 1 иллюстрирует последовательность загрузки и взаимодействия между модулями.

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

Загрузка начинается с инициализации низкоуровневых подсистем — RAM, межпроцессорных коммуникаций и так далее — обрабатываемой выделенным модулем, запускаемым в режиме EL3S сразу после включения питания CPU. Этот компонент наслаждается наивысшими привилегиями и обычно не взаимодействует напрямую с операционной системой.

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

Первая стадия, BL1, конфигурирует secure hardware ресурсы. Аппаратная изоляция ARMv8 между trusted и non-trusted памятью требует, чтобы BL1 установил secure окружение: он программирует контроллеры памяти и кэша, обозначает trusted vs non-trusted зоны и устанавливает правила DMA фильтрации. Только устройства с соответствующими атрибутами безопасности могут обращаться к соответствующим областям памяти. BL1 также строит MMU таблицы трансляции и таблицу векторов исключений, особенно Secure Monitor Call (SMC) обработчик, который может делегировать управление к последующим стадиям.

После завершения BL1, он загружает BL2 в RAM и передает выполнение через инструкцию ERET. BL2 запускается в EL1S, режиме с пониженными привилегиями, защищающим данные и код BL1 от случайных модификаций. Его основная роль — загрузить оставшиеся стадии прошивки (BL3 варианты) и передать им управление.

Третья стадия может включать до трех под-стадий, хотя BL3-2 часто опускается. BL3-1 — это trusted runtime код, с которым операционная система взаимодействует во время работы. Он содержит SMC обработчик и реализует PSCI интерфейс — стандартные вызовы для управления питанием и контролем ядер — а также vendor-специфичные расширения. BL3-2, если присутствует, работает в EL1S и служит легковесным монитором для платформенных событий таких как таймерные прерывания или периферийные сигналы.

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

Последовательность инициализации ATF суммирована на Рисунке 2.

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