К августу с.г. сразу две компании, специализирующиеся на разработке низкоуровневого ПО для персональных платформ, независимо друг от друга объявили об участии в программе сертификации ARM SystemReady. American Megatrends и Phoenix Technologies готовы в дополнение к клиентским устройствам, таким как смартфоны, планшеты и ноутбуки, поставлять микропрограммный софт для серверов на базе процессоров ARM и автономных контроллеров, управляющих электромобилями.

ARM SystemReady — это основополагающая спецификация соответствия, призванная гарантировать работоспособность программного обеспечения в динамичной и разнообразной экосистеме аппаратного обеспечения. Она унаследовала от ранее разработанной спецификации ServerReady набор требований, гарантирующих стабильность и надежность широкому кругу устройств: серверов, периферийных инфраструктур и пограничного оборудования глобальной сети. Программа сертификации удостоверяет, что системы соответствуют стандартам SystemReady. Это вселяет уверенность в том, что операционные системы и последующие уровни программного обеспечения «просто работают» в самых требовательных средах даже при экстремальных рабочих нагрузках.

Компания American Megatrends основное внимание уделяет диапазону Server Ready (SR), предлагая софт для серверных платформ на базе ARM — низкоуровневое программное обеспечение Aptio UEFI BIOS и микрокод BMC Firmware. В этой роли AMI работает напрямую со своими заказчиками и поставщиками контроллеров, поскольку они самостоятельно проходят процесс сертификации ARM SystemReady со своими ARM-конструктивами. Компания также участвует в различных группах подкомитетов, делясь своим опытом с точки зрения разработки прошивок для серверов, интернета вещей и встроенной экосистемы.
Хотя компания Phoenix Technologies официально присоединилась к программе SystemReady совсем недавно, она уже плотно работает с ARM-архитектурами. Phoenix в первую очередь сосредоточилась на диапазонах SystemReady, которые называются Server Ready (SR) и Embedded Server (ES). Это означает сертификацию ПО для работы как с традиционными серверами, так и со встроенными серверными приложениями. В портфолио компании достаточно программных продуктов, предлагающих уникальные функции платформам с ARM-процессорами. Таковыми, например, являются утилиты для безопасного стирания всех типов носителей из предзагрузочной среды, а также различные решения по обеспечению целостности и защищенности встроенного ПО.
Подводя итоги
Поднимая вопрос об унификации низкоуровневого ПО стоит принять во внимание, что такие спецификации как ACPI и UEFI разрабатывались для поддержки широкого круга платформ. Им не свойственно, как это было в Legacy BIOS, использовать для передачи параметров соглашения, оперирующие регистрами конкретных процессоров. Для процедур, абстрагированных от аппаратной реализации, исходный текст на языке высокого уровня может быть одинаков для разных аппаратных платформ и, теоретически, может быть подвергнут проверке на совместимость по заданным правилам формальной логики.
На практике микропрограммная среда состоит из огромного количества модулей, которые по определению не в состоянии быть абстрагированными от железа. Именно поэтому в спецификациях ACPI и UEFI достаточно много разделов дифференцированы для различных платформ. Код, работающий с platform-specific ресурсами, даже написанный на языке высокого уровня, не может быть платформенно независимым. Скорее, можно говорить о совместимости на уровне базового набора UEFI-протоколов, на низком же уровне кроссплатформенность часто превращается в отдельную реализацию для каждой из поддерживаемых платформ.
Одним из многочисленных примеров справедливости этого тезиса может служить декларация модели обработки прерываний, которая в ARM основана на применении контроллеров Generic Interrupt Controller (GIC). Если таблицу Multiple APIC Description Table (MADT) можно встретить в самых различных аппаратных платформах, то набор структур, размещаемых в этой таблице, существенно зависит от архитектуры процессора и модели обработки прерываний. С учетом этого обстоятельства, низкоуровневые компоненты ОС также должны быть модернизированы с целью распознавания и обработки новых видов структур.

Попытки реализовать механизмы верификации на основе набора формальных правил в x86-архитектуре отдаленно напоминает семейство документов Microsoft Hardware Design Guide. Есть и другие интересные примеры: фреймворки ChipSec или FirmwareTestSuite, предназначенные для анализа безопасности платформ PC и их совместимости с индустриальными спецификациями, включая оборудование, системную прошивку и компоненты платформы.
Вспомним о том, что во времена MS-DOS приложения могли непосредственно обращаться к аппаратному обеспечению, что иногда было продиктовано соображениями производительности, а иногда и субъективными факторами. Понимая, что ценность аппаратной платформы определяется совместимостью с огромной базой софта для PC, разработчики соблюдали аппаратную совместимость с точностью «до бита».
Так, программы, перехватывающие клавиатурный ввод, считывали скан-код символа из порта с адресом 60h в обход BIOS и DOS. Для «неканонических» контроллеров клавиатуры (в случае подключения, например, клавиатуры через USB) требовалась эмуляция, в противном случае проблема давала о себе знать немедленно. Современная аппаратная архитектура инкапсулируется драйверами, что, видимо, оптимально — в итоге, причины, порождающие ошибки стали более неуловимыми, а интеграция устройств более ответственной. Скорее всего, это и стало причиной унификации и сертификации программного обеспечения.
Если быть непредвзятым, непосредственный доступ приложений к аппаратному обеспечению в современных платформах исключен не полностью. Мотивацией для создания обходных путей снова выступает производительность, а потому сценарии доступа в обход драйверного стека можно встретить при работе с таким оборудованием, как GPU и NVMe.