Embedded Linux OTA Updates — Часть 1: Фундаменты и реализация

Необходимость обновлений

Как только Embedded Linux продукт покидает лабораторию и входит в поле, определение того, как он будет получать обновления, становится критическим дизайнерским решением.

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

Рассмотрите уязвимость Heartbleed (CVE-2014-0160), раскрывшую криптографическую библиотеку OpenSSL. Дефект затронул примерно две трети всех веб-сайтов и, по сей день, бесчисленные Embedded Linux устройства все еще поставляются с непропатченной OpenSSL сборкой, оставляя их открытыми для эксплуатации.

Block-based vs File-based Updates

Механизмы обновлений для Linux можно широко классифицировать на block-based и file-based подходы. Block обновления перезаписывают весь раздел или блок устройства в одной атомарной операции, тогда как file обновления заменяют отдельные файлы или пакеты — аналогично тому как «apt-get upgrade» работает на десктоп или серверных дистрибутивах.

Для Embedded Linux block-based апгрейды предпочтительны, потому что вся файловая система обычно производится единым build pipeline и storage footprint продукта фиксирован. Обновление целого раздела за один шаг также упрощает rollback: копия предыдущего образа может быть удержана до верификации нового.

Обеспечение восстановления после неудачного обновления

Ни одно устройство не должно оставаться в непригодном состоянии, особенно если потеря питания или сбой записи происходит в середине флешинга. Обычное смягчение — поддержание вторичного раздела, который может взять на себя, если первичный образ не загружается.

Рисунок 1. Восстановление в случае неудачи — варианты fallback (Источник: ByteSnap)

Существует два распространенных паттерна:

• Rescue-partition стратегия — загрузчик запускает маленький rescue образ, который может запустить основную прошивку после завершения обновления. Это позволяет основному разделу занимать большинство места хранения, но требует двух перезагрузок (в rescue, затем в main).
• Dual-rootfs стратегия — два полных root файловой системы держатся рядом. Загрузчик переключается между ними во время загрузки. Когда обновление применяется, неактивный образ перезаписывается, и нужна только одна перезагрузка. Этот подход halbирует доступное пространство на образ, но дает более быстрое восстановление и нулевой downtime.

Если хранилище обильно, dual-rootfs метод обычно рекомендуется за его простоту и производительность. Rescue подход полезен, когда основной образ велик и запасное пространство для дубликата rootfs ограничено.

Заметьте, что загрузчики сами обычно immutable в этой настройке. Для обновления загрузчика вам понадобился бы дополнительный bootloader раздел и Board-Management Controller (BMC), способный оркестрировать переключение — решение, увеличивающее аппаратную сложность и стоимость.

Рисунок 2. Восстановление в случае неудачи — Board Management Controller (Источник: ByteSnap)

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

Использование U-Boot Environment Variables

U-Boot хранит non-volatile окружение, которое может быть запрошено из Linux и манипулировано во время загрузки. Эти переменные идеальны для кодирования активного раздела, отслеживания успешных загрузок и оркестрации fail-over логики.

Типичные паттерны включают:

• Установку флага перед переключением на новый образ.
• Инкремент переменной «boot count» на каждой успешной загрузке.
• Сброс флага после достижения порога успешных загрузок.

Храняя это состояние в U-Boot, загрузчик может автоматически откатиться к предыдущему образу, если новый не загружается настраиваемое число раз.

Рисунок 3. U-Boot environment variables (Источник: ByteSnap)