识别嵌入式Linux设备的安全固件更新机制和开源选项

物联网（IoT）的快速增长引发了数十亿联网无线嵌入式设备的出现。从医疗设备到水箱传感器、智能恒温器、智能路灯、水监测器等，物联网的应用范围比以往任何时候都要广。

可能出现什么问题？

这些设备中的大多数在设计上都不是恶意攻击的目标。嵌入式系统传统上被认为是稳定的产品，但实施成本高昂，投资回报率（ROI）计划在相当长的生命周期内进行。一旦发货，它们很少需要更新。开发更新并在该领域实际应用它们的需求和成本随着智能手机和操作系统（OS）如Android的爆发而变得普遍。

突然之间，恶意黑客现在将所有这些易受攻击的连接设备作为潜在目标，这些设备在不充分的，过时的操作系统和Linux内核上运行，这些操作系统和Linux内核具有尚未修补的已知漏洞，并且可以远程利用！

这不是一个非常有吸引力的前景。

安全更新：嵌入式与服务器

如今，一类新的现场软件更新正在出现，这种更新受到安全问题的推动，但也允许工程师添加新功能和修复错误。

对于嵌入式设备，固件更新机制不仅必须安全，而且必须可靠，因为它要么更新成功，要么无法恢复到可恢复状态。软件更新绝不应该破坏设备，并且应该能够在无人值守的情况下发生。大多数更新还必须保留以前的设备状态，尽管在某些情况下，恢复设备可能涉及重置为默认状态。

还有原子性问题。Linux服务器世界习惯于执行基于包的更新，一切似乎都很好。但嵌入式设备不是服务器。

服务器通常位于受控环境中，可能是安全的，并且具有有保证的电源和网络连接。它还驻留在受监视的可访问位置，因此即使不希望用户进行恢复，也可以进行用户干预。

Linux 服务器通常依赖于包管理，通常是基于 rpm 的（已修改的黄色狗更新程序或 YUM）或基于 deb 的 （apt），具有执行非原子增量更新的依赖关系解析。更新由软件包版本更新驱动，每个更新都有一组复杂的安装前/安装后脚本，这些脚本可能会使系统处于未定义甚至非工作状态。

不幸的是，嵌入式设备可能无法访问，可能大部分时间都处于低功耗模式，使用寿命非常长，并且可能遭受可能中断固件更新的电源或网络中断。

最终，基于包管理器的更新不是原子的，因此很难测试和支持它们。这通常会导致丢失对设备上固件实际状态的跟踪，以及可怕的“我上次在此设备上更新了什么？”问题。这不适用于期望始终一致执行的嵌入式系统。

图像更新

更新嵌入式设备的传统且未经验证的最佳方法是执行整个映像更新。在裸机设备中，这将是包含所有设备固件的整个映像。在嵌入式Linux设备中，这通常转换为分区更新，因此分区方案是一个重要的考虑因素，因为它会影响可以执行的软件更新类型。

嵌入式 Linux 设备通常会将媒体划分为可以单独更新的不同分区：

引导加载程序分区： 很少（如果有的话）更新，在现场更新嵌入式设备的引导加载程序将导致设备最终变砖。因此，经过深思熟虑的更新机制会尽可能避免这种情况。

引导/内核分区： Linux 内核和相关工件（如设备树和 initramfs 映像）通常出于安全性而不是功能原因而发生。通常不需要更新。

根文件系统分区： 存储操作系统文件的位置通常是只读不可变的。这也很少更新，但如果应用程序依赖于此处的库，则可能会更频繁地发生这种情况。

用户分区： 用户应用程序和持久性数据的存储位置是最常需要更新的分区。

基本上，映像固件更新的范围可以从整个系统（即内核、根和用户分区）到其中一些分区。

有两种类型的映像更新是可能的：对称的和不对称的。

对称： 对称更新需要正在更新的分区映像的双重副本，以便可以在另一个正在运行时更新一个分区映像。这通常需要两个引导/内核分区、两个根文件系统以及两个用户分区。然后，引导加载程序跟踪给定引导要使用的分区。对称更新具有最短的停机时间，通常只有重新启动时间，并允许取消更新。

非 对称： 非对称更新使用通常从内存运行的恢复操作系统，具有 Linux 内核和初始化映像。这减少了所需的分区数，因为恢复模式仅存在于一个额外的分区中，并且可以更新任何其他分区。如果更新失败，可以重试恢复。非对称更新在更新时具有更长的停机时间，并且不允许用户取消。

用户空间更新程序应用程序

通常，更新由用户空间应用程序执行，该应用程序提取软件更新包，应用它，并将更新通知引导加载程序。它还需要允许进行安装后操作。然后，引导加载程序启动硬件监视程序并尝试引导。如果引导成功，则硬件看门狗被停用;如果不是，则触发它，并且引导加载程序会再次尝试引导。经过多次尝试后，它要么交换回已知良好的分区，要么进入恢复模式。

一个重要的考虑因素是用户空间更新固件必须可通过固件更新过程进行更新。另一个风险是，可能会更新到固件更新机制损坏的可启动系统。不幸的是，有必要回退到引导加载程序或其他恢复机制来更新固件。

某些系统使用引导加载程序来执行更新。这有一些严重的缺点。如果必须更新固件更新代码（例如，由于分区更改），则需要更新引导加载程序，这是非常危险的。引导加载程序在它支持的驱动程序、工具、库和网络协议的数量上也非常有限，因此更新发生在资源有限的环境中。

基于签名映像的开源软件更新有两个主要选项，同时支持对称和非对称更新：

瑞典语更新（在 GPLv2 许可证下） – 在 Yocto 中通过元更新层支持瑞典语更新（但仅限于对称更新）。它还包含一个猫鼬Web服务器，Suricatta守护进程，用于将更新从具有REST客户端的远程服务器拉取到Eclipse HawkBit ［2］（一种后端解决方案，用于将软件更新部署到终端设备）。它目前仅适用于 U-Boot 引导加载程序。

劳克 ，在 LGPLv2.1 许可证下 – RAUC 在约克托中通过元 ptx 层受支持，并支持 Grub 或裸盒引导加载程序。

远程映像更新

固件更新过程必须能够从本地源（例如，闪存、USB、μSD 或 UART）进行远程更新，也可以远程更新通常称为无线 （OTA） 更新。OTA 更新使用远程服务器将更新推送到设备上运行的客户端。

开源远程 OTA 固件更新的一些选项包括：

Mender.io ，在 Apache 2 许可证下 – Mender.io 同时用于客户端和服务器。它在约克托中通过元修正层得到支持。服务器可以充当部署服务器和生成项目管理器，但也包含设备管理控制台。

数字国际远程管理器 ，在 MPLv2 许可证下 –Digi远程管理器具有专有的基于云的服务器和开源客户端。它在约克托中通过元数字层得到支持。服务器可以充当部署服务器、生成项目管理器，还包含具有设备报告和监视功能的设备管理控制台。

Eclipse HawkBit ，在日食公共许可证下 – Eclipse HawkBit 是一个 Eclipse 公共许可证服务器，它还充当部署服务器、构建工件管理器和设备管理器，具有设备报告和监视功能。

完整映像更新通常存在大尺寸的问题，这对于带宽不自由或不宽的资源受限应用程序（如蜂窝）来说可能是个问题。差异映像固件更新是解决此问题的良好折衷方案，因为实际上只传输以前版本中的增量。

容器化更新

容器化应用程序的使用简化了软件更新用例，因为应用程序可以单独更新。

容器更新建立在不可变分发（可能是只读文件系统）上，其中应用程序仅存在于可由容器增量升级的容器中。

使用基于容器的固件更新的开源项目的一些示例如下：

Resin.io – Resin.io 是基于 Docker 的，具有专有的 OTA 更新服务器和 Apache 2 许可客户端。它通过元树脂层在Yocto中支撑。

Ubuntu “Snappy” Core–Ubuntu Core 是一个基于 Ubuntu 的最小操作系统，它提供了足够的功能来更新具有增量的类似容器的应用程序。

还有一些新的操作系统设计用于托管Docker应用程序，这些应用程序最终可能会在嵌入式空间中使用，例如CoreOS ［8］（在arm64上）和原子计划（基于Fedora / CentOS / RHEL的操作系统，使用rpm-ostree（基于lipbostree）而不是rpm）。

增量二进制原子操作系统更新

最后，嵌入式市场即将到来的趋势是增量的每文件原子更新，可以根据需要快速部署或回滚，同时保持完整的部署历史记录。

一些开源示例项目：

libOSTree– libOSTree 由一个定义为“操作系统二进制文件的 Git”的库和命令行工具组成。它使用类似 git 的对象来存储和部署操作系统增量，每个增量都有一个持久数据的副本。Yocto有一个元更新程序层可以利用它。它也用于操作系统，如项目原子。

swupd – swupd最初是 ClearLinux 的一部分，由英特尔赞助。它与 libOSTree 非常相似，在约克托中通过元-swupd 层支持。

缩小选项范围

随着物联网设备的出现，固件更新不仅仅是一件好事，而且是新产品开发所需的功能。需要尽早考虑固件更新策略的选择，因为它会影响未来的产品设计决策。与所有早期决策一样，错误的选择会给开发时间带来沉重的负担。

上市时间紧迫的项目可能会倾向于更传统的、久经考验的全映像固件更新策略。其中包括通过Yocto项目的元更新层提供的一个，以及企业就绪的OTA更新解决方案，如Digi国际的远程管理器。

然而，处于前沿的项目可以通过容器化应用程序设计扩展整个系统固件更新方法，该设计允许应用程序与系统更新隔离。

审核编辑：郭婷