Софт для ARM требует проверки на совместимость

К августу с.г. сразу две ком­па­нии, спе­ци­а­ли­зи­ру­ю­щи­е­ся на раз­ра­бот­ке низ­ко­уров­не­во­го ПО для пер­со­наль­ных плат­форм, не­за­ви­си­мо друг от дру­га объ­я­ви­ли об учас­тии в про­грам­ме сер­ти­фи­ка­ции ARM System­Ready. Ame­ri­can Mega­trends и Phoe­nix Tech­no­lo­gies го­то­вы в до­пол­не­ние к кли­ент­ским уст­рой­ст­вам, та­ким как смарт­фоны, план­ше­ты и но­ут­бу­ки, по­став­лять мик­ро­про­г­рам­мный софт для сер­ве­ров на базе про­цес­со­ров ARM и ав­то­ном­ных конт­рол­ле­ров, уп­рав­ля­ю­щих элект­ро­мо­би­ля­ми.

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

Компания American Megatrends основное внимание уделяет диапазону Server Ready (SR), пред­ла­гая софт для сер­вер­ных плат­форм на базе ARM — низкоуровневое программное обеспечение Aptio UEFI BIOS и ми­кро­код BMC Firm­ware. В этой роли 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). Ес­ли таб­ли­цу Mul­tip­le APIC Description Table (MADT) можно встретить в самых различных аппаратных плат­фор­мах, то на­бор струк­тур, раз­ме­ща­е­мых в этой таблице, существенно зависит от архитектуры про­цес­со­ра и мо­де­ли об­ра­бот­ки пре­ры­ва­ний. С уче­том этого обстоятельства, низкоуровневые компоненты ОС так­же долж­ны быть мо­дер­ни­зи­ро­ва­ны с целью рас­по­зна­ва­ния и об­ра­бот­ки новых видов структур.

Попытки реализовать механизмы верификации на основе набора формальных правил в x86-архитектуре от­да­лен­но на­по­ми­на­ет се­мей­ст­во до­ку­мен­тов Micro­soft Hard­ware Design Guide. Есть и другие интересные примеры: фрейм­вор­ки ChipSec или Firm­wareTest­Suite, пред­наз­на­чен­ные для ана­ли­за без­о­пас­нос­ти платформ PC и их со­вмес­ти­мос­ти с ин­дус­три­аль­ны­ми спе­ци­фи­ка­ци­я­ми, вклю­чая обо­ру­до­ва­ние, сис­тем­ную про­шив­ку и ком­по­нен­ты плат­фор­мы.

Вспомним о том, что во времена MS-DOS приложения могли непосредственно обращаться к аппаратному обес­пе­че­нию, что ино­гда было продиктовано со­об­ра­же­ни­я­ми производительности, а иногда и субъ­ек­тив­ны­ми фак­то­ра­ми. По­ни­мая, что ценность аппаратной платформы определяется совместимостью с огромной ба­зой софта для PC, раз­ра­бот­чи­ки со­блю­да­ли аппаратную совместимость с точностью «до бита».

Так, программы, перехватывающие клавиатурный ввод, считывали скан-код символа из порта с адресом 60h в об­ход BIOS и DOS. Для «не­ка­но­ни­че­ских» контроллеров клавиатуры (в случае подключения, например, клавиатуры через USB) требовалась эмуляция, в противном случае про­б­ле­ма да­ва­ла о себе знать не­мед­лен­но. Со­вре­мен­ная ап­па­рат­ная ар­хи­тек­ту­ра инкапсулируется драй­ве­ра­ми, что, ви­ди­мо, оп­ти­маль­но — в итоге, при­чи­ны, по­рож­да­ю­щие ошибки ста­ли более неуловимыми, а ин­те­гра­ция уст­ройств бо­лее от­вет­ст­вен­ной. Ско­рее все­го, это и стало при­чи­ной уни­фи­ка­ции и сер­ти­фи­ка­ции про­г­рам­мно­го обеспечения.

Если быть непредвзятым, непосредственный доступ приложений к аппаратному обеспечению в современных плат­фор­мах ис­клю­чен не пол­но­стью. Мотивацией для создания обходных путей снова выступает про­из­во­ди­тель­ность, а потому сценарии доступа в обход драйверного стека можно встретить при работе с та­ким обо­ру­до­ва­ни­ем, как GPU и NVMe.