Обновления OTA для Embedded Linux, часть 1 - Основы и реализация

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

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

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

Возьмем, к примеру, CVE-2104-01650 (Heartbleed). Эта уязвимость затронула библиотеку криптографии OpenSSL и, соответственно, две трети веб-сайтов в сети. Даже сейчас, три года спустя, на многих устройствах со встроенным Linux работает незащищенная версия OpenSSL, широко открытая для атак.

Блокировка обновлений по сравнению с файлами

Говоря об обновлении Linux, вы можете встретить упоминания «блочной» и «файловой» систем обновления. Это относится к обновлению всего раздела за раз путем записи прямо на блочное устройство или обновления отдельных файлов для выполнения обновления. Возможно, вы знакомы с системами обновления файлов из Desktop или Server Linux (например, «sudo apt-get upgrade»).

В Embedded Linux обновления на основе блоков являются оптимальным вариантом из-за их атомарности и того факта, что вся файловая система обычно является результатом работы системы сборки Embedded Linux. Мы ожидаем, что пространство для хранения на каждом встроенном устройстве будет постоянным для конкретного продукта, поэтому мы каждый раз создаем разделы одинакового размера. Этот тип обновления идет рука об руку с наличием какого-либо резервного образа или образа для восстановления.

Восстановление в случае сбоя

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

Рисунок 1. Восстановление в случае сбоя - варианты возврата (Источник:ByteSnap)

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

В загрузчике должен быть реализован какой-то метод определения успешности загрузки, а если нет, он должен вернуться в раздел аварийного восстановления (диаграмма слева) или в предыдущий рабочий раздел (диаграмма справа).

Метод восстановления (левый) позволяет выделить больше места для основного раздела, тогда как метод dual-rootfs (правый) требует, чтобы пространство было более или менее равномерно разделено между двумя разделами. Если пространство не является проблемой, рекомендуется использовать метод dual-rootfs только потому, что это приведет к меньшему времени простоя. Обновление с помощью метода восстановления требует двух перезагрузок:одну в раздел восстановления, а затем снова в основной. Метод dual-rootfs требует только одной перезагрузки, так как обновление можно выполнить в любое время.

Что вы не можете безопасно обновить в этих системах, так это загрузчик (или действительно раздел аварийного восстановления). Если вы хотите иметь возможность обновлять загрузчик, вам потребуются два отдельных раздела загрузчика и какой-то Board-Management-Controller для реализации логики переключения между ними.

Рисунок 2. Восстановление в случае сбоя - Контроллер управления платой (Источник:ByteSnap)

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

Переменные среды U-Boot

U-boot реализует энергонезависимую «среду», в которой могут храниться переменные. К ним можно получить доступ даже из Linux (различными способами, в зависимости от того, как хранится среда, как подробно описано на elinux.org.

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

Рис. 3. Переменные среды U-boot (Источник:ByteSnap)