LWN：2022 基于映像文件Linux峰会！

关注了就能看到更多这么棒的文章哦～

A report from the 2022 Image-Based Linux Summit

November 3, 2022
By Luca Boccassi, Lennart Poettering, and Christian Brauner
DeepL assisted translation
https://lwn.net/Articles/912774/

第一届 Image-Based Linux Summit 于 2022 年 10 月 5 日和 6 日在柏林举行。这次峰会的主要目标是就如何构建、部署和运行现代的、安全的、基于映像文件的（image-based）Linux 发行版来达成概念和工具方面的共识。这个项目的组织者 Christian Brauner、Luca Boccassi 和 Lennart Poettering 已经做了不少工作，因此对如何安全地构建和部署 Linux 系统有了更精细的设想。

峰会的动机之一，是基于这样一个简单的事实：更大范围的生态系统中也一直在同样思考这个问题。例如，我们的雇主微软已经在最近宣布的基于 ARM64 的 Azure offload SoC 中使用到了峰会上所涉及的许多概念，这个 SoC 当前运行的是一个定制的、安全加固过的 Linux 发行版。当我们在思考、改进和撰写一些能改进当前技术的新方法时，我们发现许多 vendor 都或多或少地在这个领域做一些类似的工作，并有不同程度的重复劳动。然而，这里几乎没有出现什么配合工作。峰会的目的，是确定以及达成共同概念，并提出一套初步的规范。其中一些已经有了参考实现。

因此，我们邀请了来自已知的从事着这部分工作但是来自不同 vendor 和发行版的开发团队的技术代表。峰会特意保持了较小规模，因为它希望成为一系列的对话以及头脑风暴的会议，并没有固定的议程或演讲，也就是一个 BoF 式的活动。30 名与会者在柏林的微软办公室碰面了，对作者和与会者事先列出的一系列主题进行了讨论。这些讨论主题都是围绕着利用映像文件以及增强的安全功能来发布 Linux 的想法。

与会者隶属于许多公司或项目，包括 Canonical、Ubuntu Core、Debian、Gnome OS、Fedora CoreOS、Red Hat、Endless OS、Arch Linux、openSUSE、Flatcar、Microsoft、Amazon/AWS、Meta、System Transparency、systemd、image-builder/osbuild、mkosi、rpm-ostree。作为这次峰会的结果，最终成立了 Linux Userspace API（"UAPI"）小组，这是一个给那些希望在构建、部署和运行现代 Linux 操作系统方面希望实现一些创新的人所建立的社区。它是一个包含了各种规范、文档和想法的中心集散地。相关的 uapi-group.org 网站则包含了峰会的会议记录以及指向当前的规范和想法的各种链接。

在接下来的几个月里，该小组希望能以技术深入研究（technical deep dive）的形式在这个集散地里创建各种规范。第一个就是围绕统一内核图像（UKI，Unified Kernel Images）创建的，已经可以在 Lennart Poettering 的博客上看到，这个概念会在下面介绍到。

Building Blocks for Images

systemd 项目支持的几个概念（当然也包括缩写）是许多讨论的中心主题：

• UKI（统一内核映像，Unified Kernel Image）是一个经过安全启动签名的 UEFI 可执行文件，它包含了一个内核映像、一个 initrd 映像、以及内核命令行等。UKI 可以在 EFI 上启动，并与 systemd-boot 很好地整合起来。
  

• 可发现磁盘映像（DDI，Discoverable Disk Images）是一个很好地自我描述了的文件系统映像，在很大程度上是受到 Canonical 的 Snaps 的启发，它已经被增强过，遵循可发现分区规范（DPS，Discoverable Partitions Specification）。DDI 都被封装（wrap）在 GPT 分区表中，可能包含根文件系统（或/usr/文件系统）、系统扩展（system extensions）、系统配置、可移植服务（portable services）、容器等等，所有这些都受到 dm-verity 的保护，并合并到一个映像文件中。
  

• Credentials （凭证）是用来在各组件（管理程序、固件、系统管理器、容器管理器）之间或者给系统服务传递安全数据包的。
  

• system extension（sysext）是一个 DDI，可以使用只读的 OverlayFS 来以安全和原子操作的方式 overlay 在/usr/（或/opt/）之上。sysext 可以用来扩展基础文件系统，例如，用来支持模块化（modular）但预先构建的 initrds。
  

• 系统配置（syscfg，system configuration）是一个可以 overlay 在/etc/之上的 DDI，它提供了一种安全地扩展系统配置文件的方法。这个概念仍在开发中，会支持 initrd、rootfs、系统服务、可移植服务或 nspawn 映像。
  

这些概念在 systemd 及其工具集中都已经支持了一段时间了，只有 syscfg 是个例外，此时仍在开发中。它们都支持 signed dm-verity，可以用在由内核强制的完整性保护，无论是 online 还是 offline 都可以。

目前打算将 sysext 也一直到 Fedora 39 的 initrd 逻辑中去，这样就应该可以填补 Linux 安全方案中的一个主要空缺了。到目前为止，initrd 总是在本地构建生成，并且是以没有保护的方式来使用的，既没有签名，也没有测量（measured）。因此它们实际上缺乏验证，任何能获得本地磁盘写入权限（无论是 online 还是 offline 方式）的攻击者都可以随意摆布。只要改用 UKIs，我们就可以提供一个基础的、共享的、vendor 自己构建生成的 initrd，其中提供通用的组件；此外还有一系列在需要的时候才添加的 sysext DDI，用来提供对不太常用的硬件或存储子系统的支持，比如 iSCSI 或 NFS。UKIs 的规范已经存在了。要想深入了解，读者应该参考前面提到的 blog 文章。

Configuration, building, and deployment

我们详细地讨论了如何处理各种本地配置（local configuration）。如 openSUSE 这些各种发行版，都正在推动开发者使用 libeconf，它采用了的 configuration scheme 跟 systemd 使用是一致的。在这种机制下，厂商的默认配置会放在 usr/，而在 /run 下面会有一些临时的覆盖配置，而更加长期持久的覆盖配置则需要在 etc 下。其他的，比如那些基于 OSTree 的，都是在/usr/etc/中提供默认配置，然后在创建实例时将它们复制到 /etc/中。我们在微软正在研究一种不同的方法，即 syscfg，它类似于 sysext，但是用在 configuration 上面。也会遵循同样的原则：configuration overlay 都是受到 dm-verity 的保护的、经过签名的、是可堆叠的（stackable）、并适用于整个系统或单个服务/容器。

在讨论如何构建映像时，出现了许多种可选方案。每个发行版都有自己的构建系统（猜也猜得到）。systemd 项目中提供了 systemd-repart 工具，它能识别 DDI，在每个系统上都可以运行（用来初始化分区或者 provisioning，或用于 factory reset），所以也可以指望把它用在其他用途上。mkosi image-building 工具也有不少支持者，因为它支持构建 layered sysexts 和 UKI。但是，总的来说，每个供应商都在用自己特有的定制解决方案，这种情况不太可能改变。我们希望标准化的一个领域是软件材料清单（SBOM，software bill of materials）的产生流程，参与者之间暂时达成了一些共识，即应该采用 SPDX 标准方式。一些发行版，包括 SUSE 和 Flatcar，则做得更加好，提供了完整的 SLSA provenance。

在构建好映像文件之后，下一个步骤很明显是要把它放到一个系统上。同样，每个厂商都有自己的方法。Systemd 最近引入了 systemd-sysupdate 来作为运行时工具，可以从一个（可配置的）来源获取映像文件。服务器端可能仍然是每个厂商自己独有的，但希望至少可以共享本地的客户端方案。Systemd-sysupdate 可以与 systemd-boot 以及此生态系统中的其他部分很好地整合在一起。此外，还讨论了复活 casync 并将其与 systemd-sysupdate 整合起来，从而取代现在 systemd-sysupdate 中使用的 curl。

Updates and rollback

讨论到升级相关的话题，与会者们简单讨论了如何将它引入的干扰降到最低。这是亚马逊和微软非常感兴趣的内容，因为映像升级会导致服务中断。在生产环境中，有两种互相在竞争的方案。一种是使用 CRIU，这对单进程容器来说效果最好。另一种是使用持久性内存（persistent memory），并教会每个 service 该如何利用它，从而实现利用快速内存（fast memory）来重新启动，甚至在 kexec reboot 时可以保持状态不变。对于后者来说，还需要一个标准的用户空间解决方案，但目前还没有；微软在这个方向上正在进行一些工作，但仍然是在早期阶段。有人建议在 systemd 中实现一个类似于 kexec 的 "exitrd"，允许系统在看到只有操作系统的 DDI 被更新但是内核没有改变时，可以跳过 reboot 的硬件/固件阶段，这样可以节省一些时间。在这种情况下，系统可以直接关闭 user space，放到 "exitrd" 中，将 DDI 的 mount 点换成新的位置，然后再次启动 user space。这就可以跳过 kernel 的 shutdown 和 boot 阶段了。

几乎所有的与会者都实现了某种形式的操作系统回滚（rollback）或 factory reset 机制。在发行基于映像文件的 Linux 系统时，这会非常好用；其中一个优点是能够回滚到一个已知可以正常工作的状态。不过，这些发行版之间存在着重要的差异。那些使用了 Btrfs（SUSE）的版本依赖 snapshot，而 Ubuntu Core 则提供了一个更传统的 recovery system，存放在 EFI 的系统分区中。

但是，factory reset 其实有两种不同的含义：一种是将操作系统恢复到原始版本，另一种是将整个系统恢复到出厂状态，仅抹去所有本地的数据。systemd 提供的工具长期以来一直支持后者，并且还会得到进一步加强，让 factory reset 由 UEFI variable 和/或在操作系统分区上设置的特殊 UUID 来触发。这里会引入一个新的 target unit 来作为同步位置（synchronization point），这样一来，所有那些需要在 factory reset 时发生的自定义操作都可以被自动引入了。然后，映像构建者就可以选择提供一个启动菜单（boot menu）项，让用户来触发这一功能。

其他供应商，包括安卓，则正在使用著名的 A/B 模式进行 rollback 和 update。其中一个要做的事情就是在 systemd 组件（如 systemd-cryptsetup）中使用 TPM counter 来实现安全回滚保护（secure rollback protection），因为比起依赖最终变得太大都无法管理的黑名单（denylists）来说具有更好的可扩展性。例如，仅仅为了对 BootHole 漏洞进行应对，就使用掉了 UEFI 系统中三分之一的撤销空间（revocation）；详情请见 https://github.com/rhboot/shim/blob/main/SBAT.md 。

其中一个马上达成了共识的领域就是启动阶段的评估（boot assessment）；基于图像的系统在使用 A/B 方案时，需要一种方法来表明这次启动是 "好" 还是 "坏"。可以使用“boot-complete target” 来实现这个目标。目前已经可用了，而且看起来会有更多的发行版开始使用；所有那些在做 local assessment 的 service 都可以使用它来作为同步位置（synchronization point）。Systemd 会把这一机制跟一个 timer 集成起来，如果没能在配置好的时限内达到良好的状态，就会触发 rollback 和 reboot。此外，在使用 Omaha 等高级更新协议时（例如使用开源的 Nebraska 服务器），就可以报告更新成功或失败。

Security

缺省打开基于 TPM 的安全方案，也是很多人讨论的主题。现在，在常见的 Linux 上，这种安全方案基本上都是可选打开的，也就是缺省关闭。通过切换到具有嵌入了并且签名过的 PCR policy 的 UKI，我们可以使 TPM measurement 的可预测性更加好。这意味着就可以在默认情况下自动启用 TPM-backed disk encryption，因为不再需要在每次组件改变时都重新把密钥数据封印起来（re-seal secrets）。很快会给出一份关于 signed TPM PCR policy 文档。会议同意为 PCR 建立一个 "registry"，希望帮助开发者和供应商避免冲突和重复。

在 confidential computing 环境下，人们对远程证明（remote attestation）有了很大的兴趣，出现了各种解决方案已经互相竞争的标准。在本地节点（local node）上，有一些解决方案依赖 IMA log，其他有一些依赖 TPM log，还有一些依赖于完全自定义的 registries。目前还有很多正在进行的改动，虽然基于映像文件的系统的工作在很大程度上是远程证明的前提条件，但在这次讨论中没有明确得出需要做哪些事情，也没有提出来明确的功能需求。

Conclusions and future work

参加峰会的这些项目可以分为三个阵营：image-based deployments，Ostree-based deployments，以及 Btrfs-based deployments。因此，虽然没有完全覆盖所有参与者的项目，但大家一致认为，在相当多的主题上，确实很有可能达成合作并且标准化。

最后，鉴于与会者认为这次峰会是富有成效和有好处的，大家同意在未来再次举行会议，也许会跟另一个会议同地举行，从而方便安排出差。虽然并没有在所有供应商之间就所有议题都达成完美一致，但已经有了很多的相似之处，我们建立了一系列的要做的事情，以及一个计划。由所有参与者组成的 UAPI 小组会配合起来共同收集并合作制定文件和规范。关于 DDI、DPS 和 PCR registry 的初步规范之前就提出来了，并在 UAPI 网站上公布过，此外还有更多的规范即将出台。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～