LWN：2023 Image-Based Linux 峰会！

最新推荐文章于 2024-05-15 12:58:32 发布

LinuxNews搬运工

最新推荐文章于 2024-05-15 12:58:32 发布

阅读量709

点赞数

文章标签： linux 运维服务器

原文链接：https://mp.weixin.qq.com/s?__biz=Mzg2MjE0NDE5OA==&mid=2247487939&idx=1&sn=d84d9f047a307e6b341df5e3db0f61d4&chksm=ce0d026af97a8b7c8be0c5abc6f9a88af708075794087788b1e4e6c38d879d6008c24043c68d&scene=126&sessionid=0

版权

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

The 2023 Image-Based Linux Summit

October 16, 2023

This article was contributed by Luca Boccassi
ChatGPT translation
https://lwn.net/Articles/946526/

去年的第一次基于镜像的Linux峰会（Image-Based Linux Summit）之后，于2023年9月12日在柏林举行了第二次峰会，也就是正好在微软办公室举行的2023年的All Systems Go! 2023之前的一天。这些峰会的目标是在关于基于镜像的Linux发行版的各种工程组之间寻找共同点，传达进展，并尝试一起解决共同问题的策略。组织者包括 Luca Boccassi、Lennart Poettering 和 Christian Brauner，他们欢迎UAPI Group的参与者，该组织吸引了来自许多对这一领域感兴趣的公司的开发人员，并花了整天讨论各种主题。完整会议纪要已发布在UAPI Group的网站上。

自去年以来的进展

首先讨论了自上次峰会以来取得的进展。UAPI Group成立了，拥有一个GitHub组织和一个新的网站，该网站已经开始收集与基于镜像的Linux相关的规范，包括统一内核镜像（UKI）和可发现的磁盘镜像（DDI）的规范。正在制定更多的规范，包括一项规范，以规范如何处理hermetic /usr系统上的配置文件，这些包括 systemd 用户和构建在libeconf之上的程序的用户已经熟悉的和 /etc/ -> /run/ -> /usr/ 模式。

systemd 项目已经实施了许多更改，其中许多最初是在去年的峰会上建议的。Systemd-boot 和 systemd-stub 增加了许多新功能，包括对插件的支持（签名的 PE 二进制文件，用于内核命令行的添加）。现在可以使用新的 Python 工具ukify来构建 UKI，它不依赖于 objcopy，因此支持跨架构组装镜像；这些镜像可以包含许多新的元数据字段，例如来自 TPM 的签名 PCR11 测量（signed PCR11 measurements）。

现在 systemd 会测量机器的几个组件，以便可以将隐秘信息跟 UKI 供应商、特定系统信息（例如磁盘加密密钥或磁盘 UUID）以及引导过程的特定阶段相关联。Systemd-repart 和 mkosi 现在可以在没有特权或loop设备的情况下构建镜像。它们还可以用于完全基于软件包构建 initrd，不涉及 dracut/initramfs-tools（以前由一个单独的mkosi-initrd项目实现，但现在由 mkosi 本身支持）。

在provisioning方面，现在支持SMBIOS，以向虚拟机提供只读的临时配置；此数据可以包括systemd 凭据，现在大多数 systemd 组件都支持它，包括generators。新的"confext" 类型的 DDI也受到支持，用于提供配置数据以覆盖 /etc 。现在可以在“离线”情况下（从另一个计算机）对 TPM 进行密封，只需要目标的公钥。使用完全加密的 TPM 会话，创建和固定存储根密钥（SRK）（如果尚未存在的话）。最后但同样重要的是，新增加了一个soft-reboot 机制，只重新启动用户空间，保持内核运行，这在基于镜像的系统中非常有用，以便以最小的延迟或丢失的连接和状态的代价下从一个镜像版本更新到下一个镜像版本。

发行商也在过去的一年中做出了很大努力：

NixOS 正在开发 systemd-stub 和 ukify 的 Rust 版本，以用于引导和构建 UKI；systemd-repart 和systemd-sysupdate可用。NixOS 现在在其 initrd 中提供systemd-networkd。
Flatcar 广泛使用systemd-sysext进行 OEM 软件的 A/B 更新，并提供一组脚本来构建第三方软件并使用 systemd-sysupdate 部署它。Flatcar 实现了工厂复位功能，现在将 /etc 作为只读基础的叠加层。
Ubuntu 最近在技术新闻中宣布了一款默认启用 TPM 支持的桌面版本的消息，这是峰会参与者的主要目标之一。Ubuntu 使用 systemd-stub 来进行基于 Snap 的内核更新，以及预计算 TPM 密封的 PCR。
GNOME OS 已经支持 systemd-boot，现在还使用 systemd-repart 进行首次引导时的分区。GNOME OS 部署 UKI，并使用 dracut 构建的 initrd。
SUSE 稳步朝着在各种操作系统版本中使用 systemd-boot 迈进，包括MicroOS，YaST 安装程序已经得到改进，以支持这一点。Aeon，以前是 MicroOS Desktop，是一种新的基于镜像的版本，支持 systemd-boot、基于镜像的更新和默认的全盘加密，并正在探索添加对 systemd-homed 的支持，以管理用户和家目录。Tumbleweed 已经完全支持 hermetic /usr=，不再在 =/boot 下分发文件；正在进行工作以将默认配置文件从 /etc 移动到 /usr 。
Fedora 安装程序 Anaconda 增加了对使用 systemd-boot 替代 GRUB 安装系统的本地支持。

最后，UKI 支持正在扩展到其他项目；已经提出了允许从GRUB加载它们的补丁，而OSBuild已经原生支持构建它们。

正如预期的那样，过去一年大部分的关注都集中在改进引导安全性的问题上。在这个领域，Linux 长期以来一直落后于 Windows 和 macOS，看到如此大规模的共同的努力来填补这一尴尬的差距是令人振奋的。

hermetic /usr 和 sysext/confext

最近，围绕 sysext 和 confext 的讨论逐渐增多。这两者都是扩展镜像或 DDI 的类型，提供只读的根文件系统的附加内容，分别扩展 /usr 和 /etc 层次结构。目前，sysext/confext 的overlay是只读的，这引发了一个问题，即是否应该添加可选的可写层或模式，尽管不用作为默认设置。此模式可以是临时的或持久的。此外，还有一个提议，将 OS 层移到堆栈的顶部；它目前位于底部。有关使用符号链接解决这些问题的建议，目前正在进行工作，并且还有一个关于引入 sysext 规范中的排序保证的想法，该想法是在峰会结束后不久实施。

基于镜像系统的配置管理

这个讨论有两个方面。首先，问题是如何将配置传递到虚拟机中。一个常见的机制是由cloud-init提供的，并通过一个伪网络连接。这远非最佳解决方案，因为需要进行完整的网络握手，这很慢、麻烦，而且充满了特定供应商相关的陷阱。改进这一流程的一个想法是使用网络命名空间加上虚拟路由和转发（VRF），以便像 cloud-init 这样的工具可以在不影响系统的其余部分的情况下拥有自己的私有网络连接到本地的 hypervisor/cloud 设备。

更好的选择将是根本不使用基于网络的机制。Systemd 支持 SMBIOS 类型 11 对象，这些对象已经受到 QEMU 和 Cloud Hypervisor 的支持。这些对象对于用户的虚拟机效果很好，但对于一些云供应商来说，它们的支持有问题，因为 SMBIOS 字符串需要在提供所需配置数据之前进行修复。提出的一种替代方案是由固件或 hypervisor 提供的新 ACPI 驱动程序和伪设备，它们在请求时以阻塞模式实时生成数据。Systemd 将提供 initrd 中的同步点，使服务能够连接并生成 systemd 凭据；然后 systemd 将重新加载配置，继续执行过渡，并退出 initrd 阶段。

这实际上相当于在引导过程中添加第三个阶段，在initrd中，因为第一个阶段执行所需操作的结果是额外的资源在可用之前可用，然后过渡到rootfs。后一部分将相对容易实现，而ACPI驱动程序将是最困难的工作。如果云供应商自愿做这项工作，那么它可以很容易地集成。

第二个子主题涉及服务如何使用配置文件；SUSE多年来一直在上游项目中添加对libeconf的支持。虽然取得了一些进展，但某些应用程序，如apache2和nginx，仍然依赖于/etc中的文件才能正常运行。复杂的配置文件，通常以XML格式出现，也带来了一些挑战。Fedora已经引入了补丁来解决这些问题，展示了实现/usr的密封工作的不断努力。

主要需要做的动作是创建一个跟踪问题，列出仍然需要更新以支持这种配置模型的上游项目，以便贡献者可以合作来缩小列表。虽然工作还没有完成，但在这个主题上的情况比几年前好多了，这要归功于许多利益相关者的工作。最后，最近发布了一份关于libeconf和systemd如何处理配置文件的规范，旨在供实施自己的配置加载的开发人员使用。

Systemd凭据

仍然在配置的主题上，提出了一个问题，即如何更新systemd凭据。目前，它们是静态的；服务在启动时接收其凭据，直到服务本身重新启动后它们都不会改变。对于很多用例来说，这已经足够了，但对于一些用例来说却不够；例如，对于对中断敏感的服务，可能需要定期更换证书。通常建议的模式是使用文件描述符存储来实现快速重启（提出的一个问题是缺乏关于这个systemd功能的文档，这个问题在峰会结束后很快得到解决）。但在某些情况下，服务中断对于这种配置更新来说是太昂贵的。

幸运的是，已经计划将confext功能集成到“重新加载”机制中，这通常用于向服务发送SIGHUP信号，以便在更新时重新加载confext堆栈。凭据也可以使用相同的模式；在重新加载时，凭据会被重新打开并更新，以便执行无中断的更新。

还提出了另一个问题：目前的文档规定，加载的凭据路径必须从环境变量中派生，这对于不支持环境变量或搜索路径的项目来说是有问题的。但事实证明，这是因为用户单元（user unit）的设置，这些用户单元依赖于用户ID；对于系统服务来说，它是固定的。文档将被更新以澄清这一点，希望能消除被采用的路径上的（小）障碍。

另外，还提到目前没有一种方法来枚举现有的凭据；建议改进systemd-creds工具来完成这项工作。正在进行的另一个未来改进是基于非对称TPM加密，以便可以使用目标的TPM公钥，远离主机，对凭据进行加密。目前只支持对称加密，这可能很麻烦，因为它需要共享密钥。

/efi vs /boot vs /boot/efi vs /run/efi

关于EFI系统分区（ESP）的挂载点的争论仍在继续。问题在于当Linux扩展引导（XBOOTLDR）分区和ESP同时存在时，默认情况下不清楚每个分区应该挂载到哪里。一般来说，ESP是存储引导加载程序的地方，而XBOOTLDR是存储内核（和initrd）的地方，因为它们可能需要更多的磁盘空间。SUSE基于RPM的文件系统创建基本目录，这对于作为挂载点的顶层目录可能会有问题。讨论了使用自动挂载的建议，质疑了手动挂载这些目录的必要性。

有各种不同的工具包括bootctl、fwupd、kernel-install和systemd-logind，都需要访问这些位置以完成各种任务。挑战在于确保这些工具不会重复挂载目录。有一个提议建立处理这些路径的一致性标准和API，以及有关默认目录位置和与其他规范冲突的讨论。首要任务是协调可发现分区规范和引导加载程序规范，以便它们建议相同的方法；这在峰会后不久得到了修复。是否可以使用bootctl提供一个统一的接口来访问EFI分区也将被探讨。

TPM

测量引导领域的工作是去年峰会的焦点之一，今年也不例外。在简要回顾了所有已完成的工作，包括根据签名策略进行密封的工作，以便只有从同一供应商的引导镜像才能被托付解密的密钥，注意力集中在即将到来的开发上，该开发还将允许根据本地计算机的状态进行密封。

即将推出的systemd-pcrlock工具将允许根据包括固件拥有的PCR零到七在内的策略进行密封，但该策略也可以在应用固件更新时暂时放宽（如果系统处于已知的良好状态）。这些更新可以选择提供预期测量的列表（以TCG CEL-JSON格式提供），该列表将用于新策略。如果不提供这些测量，下次启动过程将重新测量并将新状态添加到策略中，使其再次变得严格。这确保了攻击者不能简单地在启动自己的系统时放宽策略，因为策略只能在系统处于已知的良好状态时更改。如果供应商提供测量文件，那么安全性永远不会下降，甚至不会暂时下降。这个功能相对于当前状态来说是一个重要的进展，当前状态需要在每次更新时重新密封密钥，从而改变磁盘的超级块，使其基本上不可能密封很多对象（例如systemd凭据）。

为了开发这个功能，必须向systemd添加一个只追加的事件日志，因为测量需要回放。这个事件日志紧密遵循TCG事件日志规范，因此可以轻松地将其转换为该格式或从该格式转换过来。讨论了是否为它提供API，以便应用程序也可以消耗或追加到事件日志；如果有人愿意实现，这个想法是可以接受的。

还有一些需要一些工作的特殊情况 — 对于kexec，目前还不清楚最佳的行动方案是什么。目前的想法是更改策略以测量一次随机数，并期望新内核提供该随机数，以便只有下一个内核才能成功验证。此外，在工厂复位时，将丢失测量的几个特定于机器的标识，因此需要找到一个解决方案。Ubuntu Core在安装时存储了一个加密对象，允许这种复位，而systemd应该增强以提供相同的功能。

最后，还讨论了TPM的非磁盘加密用途，以评估兴趣。已经提到了systemd凭据的用例，但还有其他用例，主要是远程证明。System Transparency提供了用于此目的的OSS工具，Keylime也提供了类似的工具，它已经集成到SUSE MicroOS中。

统一内核和预构建的initrd

关于统一内核和预构建initrd的讨论很简短，因为大部分工作已经完成并得到了参与者的支持。主要的新闻是关于附加功能，它允许平台所有者的可选增强功能添加到操作系统供应商的镜像上。目前仅支持内核命令行扩展，支持DTB正在审核中，下一个要做的是initrd附加功能。最后，新的部分可能会在UKI规范中进行文档记录；这些包括支持嵌入式微码，以便它可以首先加载到传递给内核的即时生成的initrd中，因为这是已建立的协议。

systemd-sysusers和“user”用户

关于systemd-sysusers和“user”用户的讨论侧重于添加一个开关，以复制/etc/skel，以便它也可以用于“普通”用户，而不仅仅是“系统”用户。这将是一种轻量级的集成，专注于对家目录和/etc/skel的支持。

在openSUSE Aeon中的systemd-homed

最后讨论的主题是systemd-homed，以及其在SUSE Aeon中的集成尝试。这一努力遇到了一些问题，但看起来大多数问题已经解决或正在解决中。

第一个问题是规划。由于分区必须根据用户的数量准确调整大小，因此这需要事先知道。有两种解决这个问题的方法：首先，通过使用Btrfs子卷，问题完全消失，因为无需调整分区的大小，空间会根据需要动态分配。但是，Btrfs尚不支持子卷的本机加密，尽管正在进行相关工作。GNOME也正在进行互动调整分区所需的接口的工作。

第二个问题是集成到桌面GUI中，目前尚不完善，但同样，GNOME正在努力实现，以便homed用户管理完全集成到GNOME帐户管理中。此外，讨论了关于homed的上游SELinux策略的缺失问题，但Fedora正在进行相关工作以支持它。

最后，讨论了如何正确调整/home与根文件系统的相对大小。Android使用dm-linear创建实时分区“扩展”，无需重新分配数据；systemd-repart和homed可以改进以使用相同的模式，以便可以在这两个分区之间便宜地重新分配空间。另一种方法可能是只有一个分区，并依赖于Opal自加密驱动来保护根目录的内容。