Команды нашей компании на протяжении долгого времени сотрудничают с лидерами полупроводниковой индустрии в проектах по разработке firmware под различные платформы. Инженерным командам приходилось решать множество задач на основе как стандартизированных подходов типа IPMI, OpenBMС, так и реализаций UEFI или ATF для специфичных платформ. Нижеприведенная статья обобщает опыт наших разработчиков в области обновления firmware.

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

Стремясь повысить качество продуктов, компании-производители оборудования устраняют критические ошибки и уязвимости, найденные во встроенном ПО, и регулярно снабжают пользователей исправленными образами прошивок. Также они предоставляют утилиты для прошивания образов в оборудование (обычно прошивка хранится в энергонезависимом устройстве хранения данных типа flash-памяти).

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

Поэтому к реализации процесса обновления встроенного ПО предъявляются объективные требования:

  • защита от прошивки нецелевого или поврежденного ПО. Если прошивка не предназначена для целевого оборудования, или если целостность образа нарушена, процесс обновления должен предупредительно завершиться до того, как будут осуществлены необратимые изменения, ведущие к потере функциональности оборудования;
  • устойчивость к внешним факторам, возникающим в процессе обновления, в результате которых процесс обновления может неожиданно прерваться (например, отключение питания электросети);
  • возможность восстановления до работоспособного состояния после воздействий внешних факторов, устойчивость к которым не достигается или невозможна;
  • немаловажным является также удобство организации процесса обновления (user experience).

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

Еще острее вопрос обновления ставится в случае серверных платформ. Серверные платформы проектируются так, чтобы процессы обслуживания минимально влияли на выполнение их основных функций. Переход в специальную оболочку для обновления, когда остальные функции системы недоступны, может быть допустимым в случае рабочей станции или настольного ПК, но в случае сервера это практически недопустимо. Издержки, связанные с потерей доступности сервера на время обновления, могут дорого стоить и стать причиной выбора конкурентных серверных решений. То же касается и удобства организации самого процесса обновления, когда речь может идти об одновременном обновлении десятков, сотен и даже тысяч развернутых серверов.

Таким образом, в случае серверных платформ дополнительно к уже существующим требованиям добавляются следующие:

  • минимизация времени вывода сервера из строя;
  • возможность обновления отдельных компонентов встроенного ПО, если ПО состоит из нескольких компонентов, которые можно обновлять независимо друг от друга;
  • возможность обновления оборудования без прямого доступа к оборудованию (удаленно);
  • возможность масштабировать единый процесс обновления на множество машин.

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

До недавнего времени компании-производители зачастую вынуждены были использовать проприетарные решения по обновлению ПО со всеми их недостатками: ресурсоемкость разработки и поддержки, узкий спектром применения. Однако в последнее время набирают популярность стандартизованные подходы. Это неудивительно, учитывая их доступность, относительную дешевизну, совместимость между собой и поддержку большого коммьюнити заинтересованных разработчиков. Так, для серверных решений с поддержкой IPMI разработана спецификация HPM.1, которая реализует как модель данных, так и протокол обновления, удовлетворяющий большой части типовых требований к процессу обновления встроенного ПО. Например, HPM.1 позволяет производить обновления удаленно, при этом проверяется целостность образа, а также сверяется его целевая платформа. В то же время HPM.1 позволяет разбивать встроенное ПО на компоненты, которые можно обновлять по отдельности. Процесс обновления разбивается на стадии, позволяющие масштабировать процесс обновления ПО на множество систем. Например, загрузка образа и его активация являются отдельными стадиями, что позволяет синхронизовать активацию загруженных компонентов между несколькими серверами, тем самым снижая время вывода сервисов из строя.

На аппаратном уровне требования к процессу обновления реализуются несколькими мерами. Первая — внесение избыточности. Зачастую на сервере предусматриваются две или более копии прошивки, возможно, находящиеся на разных устройствах хранения. Типовые алгоритмы предполагают переключение активной прошивки между устройствами с каждым новым обновлением либо использование только одной активной прошивки для всех обновлений, но с переключением на «известно работающую» прошивку, если основная оказалась неработоспособной.

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

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

Автор статьи — инженер-разработчик, «Аурига».