嵌入式Linux - 部署固件更新的机制？ [英] Embedded Linux – mechanism for deploying firmware updates?

问题描述

我正在考虑开发一个嵌入式Linux项目（工业应用程序）的Yocto项目，而对于具有嵌入式Linux经验的人来说，我有几个问题 - Yocto经验奖励。只需要了解固件更新中通常会做什么。

我有一些要求，即认证，安全通信协议，某种类型的回滚如果更新失败。另外，如果有一种方法可以逐渐释放整个装置的补丁程序，那么这也是很有意思的，因为我想避免在这个领域中出现的bcrked设备。

您现在是否在现场设备中部署更新/修补程序，以及开发多长时间？还有其他的缺点吗？

解决方案

虽然您可以使用rpm，deb或ipk进行升级，但我最喜欢的方式大小的图像）是将两个图像存储在闪存上，并且仅更新完整的rootfs图像。

今天，如果要使用OpenEmbedded / Yocto Project开始使用嵌入式Linux，我可能会看看meta-swupdate。

我一直在为自己和多个客户端使用这样的东西：

• 容器升级文件是由另一个tarball（以下称为升级文件）组成的tarball，升级文件的md5sum，通常是gpg-signature。


• 存储在正在运行的映像中的更新脚本。此脚本负责解压缩升级文件的外部容器，使用md5sum验证升级文件的正确性，并经常验证加密签名（通常以gpg为基础）。如果更新文件通过这些测试，则updater脚本会在更新文件中查找升级脚本，并执行此操作。


• 更新文件内的升级脚本执行实际升级，即通常重写非运行映像，提取和重写内核，如果这些步骤成功，则指示引导程序使用新写的内核和映像，而不是当前运行的系统。

在升级文件中执行实际升级的脚本的好处是，您可以在将来做任何所需在一个单一的步骤。我做了特殊的升级映像来升级连接的调制解调器的FW，或者提取了一些额外的诊断信息，而不是进行实际的升级。这种灵活性将在未来得到回报。

为了使系统更可靠，引导加载程序会使用一个名为bootcount的功能，可以启动尝试次数，如果此数字超过阈值，例如3 ，引导加载程序选择引导其他映像（因为配置为引导的映像被认为是错误的）。这样可确保图像完全损坏，其他存储的图像将自动启动。

此方案的主要风险在于您升级到升级机制已损坏的映像。通常，我们还在引导程序中实现某种恢复机制，使引导程序可以重新整理一个全新的系统;虽然这种救援机制通常意味着数据分区（用于存储配置，数据库等）也将被删除。这部分是为了安全（不泄漏信息），部分是为了确保在这次救援行动之后，系统状态将被我们完全了解。 （这是由一个没有经验的技术人员执行的很远的好处）。

I am considering developing on the Yocto project for an embedded Linux project (an industrial application) and I have a few questions for those with experience with embedded Linux in general -- Yocto experience a bonus. Just need to get an idea of what is being commonly done in firmware updates.

I have a few requirements, that being authentication, a secure communications protocol, some type of rollback if the update failed. Also, if there is a way to gradually release the patch across the fleet of devices then that would also be interesting as I want to avoid bricked devices in the field.

How do you deploy updates/patches to field devices today – and how long did it take to develop it? Are there any other considerations I am missing?

解决方案

Although you certainly can use rpm, deb, or ipk for your upgrades, my preferred way (at least for small to reasonably sized images) is to have two images stored on flash, and to only update complete rootfs images.

Today I would probably look at meta-swupdate if I were to start working with embedded Linux using OpenEmbedded / Yocto Project.

What I've been using for myself and multiple clients is something more like this:

• A container upgrade file which is a tarball consisting of another tarball (hereafter called the upgrade file), the md5sum of the upgrade file, and often a gpg-signature.
• An updater script stored in the running image. This script is responsible to unpack the outer container of the upgrade file, verify the correctness of the upgrade file using md5sum and often to verify a cryptographic signature (normally gpg based). If the update file passes these tests, the updater script looks for a upgrade script inside the update file, and executes this.
• The upgrade script inside the update file performs the actual upgrade, ie normally rewrite the non-running image, extracting and rewriting the kernel and if these steps are successful, instruct the bootloader to use the newly written kernel and image instead of the currently running system.

The benefit of having the script that performs the actual upgrade inside the upgrade file, is that you can do whatever you need in the future in a single step. I've made special upgrade images that upgrades the FW of attached modems, or that extracted some extra diagnostics information instead of performing an actual upgrade. This flexibility will payoff in the future.

To make the system even more reliable, the bootloader users a feature called bootcount, which could the number of boot attempts, and if this number gets above a threshold, eg 3, the bootloader chooses to boot the other image (as the image configured to be booted is considered to be faulty). This ensures that of the image is completely corrupt, the other, stored image will automatically be booted.

The main risk with this scheme is that you upgrade to an image, whose upgrade mechanism is broken. Normally, we also implement some kind of restoration mechanism in the bootloader, such that the bootloader can reflash a completely new system; though this rescue mechanism usually means that the data partition (used to store configurations, databases, etc) also will be erased. This is partly for security (not leaking info) and partly to ensure that after this rescue operation the system state will be completely known to us. (Which is a great benefit when this is performed by an inexperienced technician far away).

这篇关于嵌入式Linux - 部署固件更新的机制？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！