IoT固/软件更新及开源选项

物联网的迅速发展涌现了数十亿与互联网连接的无线嵌入式设备。 从医疗设备到坦克传感器, 智能恒温器, 智能路灯, 水监视器等等, 物联网比以往任何时候都应用广泛。

会出什么问题呢？

大多数这些设备的设计都不像是被恶意攻击的目标。 嵌入式系统传统上被认为是稳定的产品, 但实施起来成本高昂, 因为投资回报率(ROI)在的周期比较长。 在过去一旦发货, 就很少需要更新这些设备。 随着智能手机和RTOS的爆发, 才使得固件更新以及应用更新的必要性凸显出来。

假想一下, 恶意黑客将所有这些易受攻击的连接设备作为潜在攻击目标的话, 这些设备运行在不安全或过时的Linux 内核上, 有些漏洞还没有被修补过, 并且可以被远程控制！

这可不是一个有吸引力的场景。

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

如今, 升级安全问题驱动了IoT软件的升级更新, 也提高了工程师添加新的功能和修复漏洞可能性。

对于嵌入式设备, 固件更新机制不仅必须是安全的, 而且是可靠的, 因为它要么成功更新, 要么失败到可恢复状态。 一般地, 很难在用户现场升级固件，而需要在无人看管的情况下完成自动升级。 大多数更新也必须保留先前的设备状态, 尽管在某些情况下恢复设备可能涉及将系统重新设置为默认状态。

还有一个原子性问题。 Linux 服务器世界已经习惯于执行基于软件包的更新, 所有的东西似乎都能运行良好。 但是嵌入式设备则不一定。

服务器通常运行在一个可控的环境中, 可能是安全的, 并且有电源的保障和网络连接。 也就是说位于一个受监控的、可访问的位置, 用户干预恢复是可能的, 即使并不是必要条件。

Linux 服务器通常依赖于包管理, 基于 RPM (或 YUM)或基于 deb 的apt , 具有非原子增量更新的依赖辨识。 由包版本更新驱动流程, 每个都有一组复杂的预安装脚本, 这些脚本可能会让系统处于一个未定义的状态, 甚至是非工作状态。

不幸的是, 嵌入式设备可能无法访问, 大部分时间可能处于低功耗模式, 有很长的存活周期, 可能会遭受电力或网络中断的困扰, 从而中断固件升级。

总之, 基于包管理器的更新不是原子的, 因此很难测试和支持它们。 这通常会导致对设备固件实际状态的跟踪, 以及令人畏惧的"上次更新了什么?" 等问题。 这种方法不适合嵌入式系统, 因为这些系统会要求始终保持一致性。

镜像更新

更新嵌入式设备的传统最佳方式是对镜像进行整体更新。 在设备中, 这将是整个镜像和所有的设备固件。 在嵌入式 Linux 设备中, 这通常转化为分区更新, 所以分区方案是一个重要的考虑因素, 因为它将影响可以执行的软件更新类型。

嵌入式 Linux 设备通常将媒介分为不同的分区, 可以分别更新:

Bootloader 分区: 如果有的话, 很少更新, 更新嵌入式设备的引导程序最终将导致设备最终被退出。 因此, 完善的更新机制应尽可能避免这种情况。

引导 / 内核分区: Linux 内核和相关固件, 如设备树和 initramfs 镜像,除非为了安全，通常不需要更新。

根文件系统分区: 存储的 OS 文件通常是只读且不可变的。 这也很少更新, 但如果应用程序依赖于这里的库, 可能会发生较多的更新情况。

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

基本上, 固件镜像更新可以从整个系统：内核、根和用户分区到其中的某些部分。

有两种可能的镜像更新: 对称和非对称。

对称: 对称更新需要更新分区镜像的双重副本, 以便可以在另一个运行时完成更新。 这通常需要两个引导/内核分区、两个根文件系统以及两个用户分区。 然后, bootloader 会跟踪哪些分区用于给定的引导。 对称更新的停机时间很小, 通常只有重启时间, 并允许更新取消。

非对称: 非对称更新使用了一个通常由内存运行的恢复操作系统, 它有一个 Linux 内核和 initramfs 镜像。 这样就减少了所需的分区数量, 因为恢复模式只在一个额外的分区中存在, 并且可以更新其他任何分区。 如果更新失败, 可以重新尝试恢复。 不对称更新在更新时会有较长的下行时间, 并且不允许用户取消。

用户空间更新