关于无线更新

汇报是 Azure Sphere 安全模型的重要组成部分,因为它们体现了可更新安全性的属性。 确保定期进行更新有助于使设备符合 7 属性 要求。 Azure Sphere 设备在开机后或按下“重置”按钮后首次连接到 Internet 时,检查更新。 此后,检查定期进行, (当前 20 小时) 。

有三种类型的更新: 先决条件更新OS 更新部署更新。 先决条件更新用于确保更新过程本身所依赖的组件(当前受信任的密钥存储 (TKS) 和证书存储)是最新的。 TKS 用于对要下载和安装的图像进行身份验证,而证书存储用于验证 Internet 连接。 OS 更新面向设备上 Microsoft 提供的软件,包括运行应用程序的正常操作系统,以及 Pluton 子系统和安全监视器等较低级别的固件。 部署更新面向你自己的软件 -- 高级且支持实时的应用程序和板配置映像 ((如果有任何) )。 先决条件和 OS 更新由 Azure Sphere 管理;应用程序更新由 Azure Sphere 根据组织创建的 部署 进行协调。

若要让任何设备接收先决条件或 OS 更新:

  • 它必须连接到 Internet。
  • 必须正确配置网络要求

为了让任何设备更新其应用程序和板配置映像:

  • 不得 具有 应用程序开发功能
  • 它必须由 目录声明
  • 它必须属于 设备组
  • 它所属的设备组必须成为部署的目标。
  • 部署必须包含应用程序映像 (,以及(可选)由组织或代表组织创建的板配置映像) 。
  • 设备组必须具有 UpdateAll 更新策略。 可以使用 az sphere device-group update 命令禁用特定设备组的应用程序更新。

对于给定设备组中的所有设备,针对该设备组的部署被视为这些设备映像的事实来源。 设备上不存在于部署中的任何映像都将从设备中删除。 自 Azure Sphere OS 21.04 起,一个例外是,除非将其替换为新的板配置映像,否则不会删除这些映像。

设备更新检查在对应于三种类型的更新的三个阶段中发生:

  • 在第一阶段,Azure Sphere 获取一个清单,其中列出了当前版本的 TKS 和证书存储。 如果设备上的 TKS 和证书存储是最新的,则更新将继续执行第二阶段。 否则,将下载并安装当前映像。
  • 在第二阶段,Azure Sphere 获取一个清单,其中列出了各种 OS 组件映像的当前版本。 如果设备上的任何映像已过期,则会下载当前映像以及 回滚映像 ,这些映像可用于在更新过程失败时将设备回滚到已知的良好状态。 OS 和回滚映像将下载并存储在设备上的暂存区域中,然后安装 OS 映像并重新启动设备。
  • 在第三阶段,如果设备组接受部署更新,Azure Sphere 会检查部署更新。 与 OS 更新一样,应用程序的回滚映像也会根据需要暂存。 应用程序和回滚映像下载并存储在暂存区域中,然后安装应用程序映像。

更新回滚

更新过程的每个部分都包含一个回滚选项。 在先决条件更新中,回滚映像只是更新前状态的备份。 如果更新失败,则会还原更新前状态。

在任何级别回滚会强制在所有较高级别回滚:如果任何固件映像无法启动,则会回滚固件和应用程序分区。

对于 OS 更新,签名验证失败或运行时困难可能会触发回滚。 如果签名验证失败,将尝试更正映像;如果此操作失败,则会触发完全回滚。 在完整回滚中,将同时为 OS 和应用程序安装暂存回滚映像。

OS 更新和部署具有独立的发布周期,因此 OS 更新之间可能会发生多个部署。 如果发生这种情况,请务必注意,部署的回滚目标不是最新的部署,而是上次 OS 更新时的部署。 这可确保 OS 和应用程序在回滚状态下协同工作。

中断的更新

如果更新中断(例如电源中断或连接中断),则每种更新类型有四种可能的方案:

  • 如果成功下载并暂存了一组完整的映像,但尚未安装,则恢复电源后,安装将完成。
  • 如果部分映像(但不是全部)已下载并暂存,则更新将继续下载缺少的映像,然后继续安装。
  • 如果在下载完成后安装过程中中断更新,则安装将在启动时重新启动。
  • 如果未完全下载映像,则恢复电源后,更新过程将重新开始,因为不会有任何准备安装。

在断电方案中汇报

Azure Sphere 支持低功率方案,使设备能够长时间 断电 以节省电池使用时间。 在这种情况下,必须允许设备定期检查更新。 关机示例应用程序演示了如何正确降低功耗,同时仍确保设备会定期保持唤醒状态,以检查进行 OS 和应用更新。

延迟更新

为了防止关键任务被更新中断,高级应用程序可以合并 延迟更新。 此功能允许应用程序完成其关键任务,然后准备关闭以允许更新继续。 DeferredUpdate 示例演示如何实现此类延迟更新。