LWN：针对完整性保护以及数据共享设计的Composefs！

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

Composefs for integrity protection and data sharing

By Jake Edge
December 7, 2022
DeepL assisted translation
https://lwn.net/Articles/917097/

最近在 linux-kernel 邮件列表中提出了一个只读文件系统的 RFC，希望用它来在不同的目录树之间透明地共享文件数据，同时也为数据和目录 metadata 提供完整性验证。这个 Composefs 是由 Alexander Larsson（发布者）和 Giuseppe Scrivano 共同开发的，用在 podman 容器和 OSTree（或现在称为 "libostree"）root 目录方面，但也可能有其他人会希望使用它所提供的功能。目前为止都没有看到什么反馈或者是抱怨，但它是一个很小的 patch set（大约两千行代码），而且基本上是比较独立、自成一体的，因为它毕竟是一个文件系统，所以确实有可能会出现在不久之后的 kernel 中。

Features

在 patch 的 cover letter 说明中有对于 composefs 的长篇介绍，在 documentation patch 中有更多信息。跟许多文件系统不同的是，composefs 的底层不是一个普通块设备，而是一组普通的只读文件：一个包含目录结构和文件 metadata 的 image 文件，以及一个目录其中都是一些 content-addressed object 来作为文件内容。由于这些文件本身是在一个对象存储（object store）中，因此重复文件来说就可以避免浪费空间了，也就是说具有相同内容的文件只被存储一份，哪怕 metadata（如所有者、权限、扩展属性等）有差别。此外，每当从 composefs 读取文件时，都会使用底层的对应文件，并且缓存在 page cache 中，所以如果有另一个 composefs 文件读取其实需要的是相同内容的话，那么也会使用这个 page-cache 条目。

对象存储中使用的文件名是对应着文件内容的 fs-verity 摘要的，因此 composefs 可以使用 fs-verity 机制来检测文件的变动。image 文件可以包含文件的摘要，确保它们不会在 composefs 之外被改变，并且 image 文件本身也可以用 fs-verity 保护起来。image 文件的 fs-verity 摘要可以是从一个安全的地方（比如签名保护过的的内核命令行）来获取，并传递给 mount 命令，让 composefs 确保整个文件系统都是跟它的预期状态匹配得上的。

一个 composefs 实例中所需的那些文件是用 mkcomposefs 工具创建的：

$ mkcomposefs --digest-store=objects rootfs/ rootfs.img

这个命令会对 rootfs 目录进行处理，将其目录结构和文件 metadata 对应的 image 文件存储在 rootfs.img 中，并将文件内容作为一个新创建的对象存储放到 objects 目录里去。object 目录下跟 Git 中的做法类似，使用了摘要哈希值的前两个十六进制字符命名这些子目录，每个子目录都包含以哈希值其余字符作为名字的文件。
以这种方式创建的文件系统可以按如下方式挂载。

$ mount -t composefs rootfs.img -o basedir=objects,verity_check=2 /mnt

verity_check 选项控制着是否对 image 和所有文件进行 fs-verity 检查；0 会禁止 fs-verity 检查，1 是只检查指定的 image，2 表示需要 fs-verity。还有一个 digest 选项，可以用来将 image 文件的 fs-verity digest hash 传递给 mount 命令，这样 composefs 就可以对它进行验证了。这就提供了 cover letter 中所提到的端到端验证（end-to-end verification）。"所以，只要使用了一组可信的 mount 选项（比如是从 TPM 解锁而来），我们 mount 上来的就是一个完全验证过的文件系统 tree，并有机会对相同的文件进行细粒度的共享。

Use cases

系统中的多个容器经常会共享许多文件，但这些文件数据通常都要在每个容器 image 里复制一份。Composefs 可以用来创建多个不同的、只读的容器镜像文件，这些文件都指向同一个对象存储，因此所有的文件都只需要存储一份。此外，被多个容器同时使用的文件（如共享库）就可能会驻留在 page cache 中，从而节省了从持久性存储（persistent storage）中获取这个数据的速度。

Larsson 和 Scrivano 所设想的第二个用途是用 composefs mount 来替代“link farm” （基于 OSTree 的 root 文件系统中会创建）。目前，OSTree 使用了 hard link 硬链接来指向它的内容寻址的对象存储（content-addressed object store），但这个结构不阻止修改，因为它在运行时没有进行验证，只有在创建时才会被验证过。相反，通过在 image 文件和对象存储上使用 fs-verity，这些基于 composefs 的 root 文件系统就会自动保护其完整性。

除了 composefs 的这两个直接用途之外，还有其他的用途在酝酿之中：

[……]似乎还有很多其他可能的用途。例如，许多系统对 image 都使用了 loopback mount 方式（如 lxc 或 snap），这些都有机会利用共享优势的。我们还谈到了使用 fuse [用户空间中的文件系统] 来实现对底层文件实现本地缓存。也就是说，你可以让第二个 basedir 采用 fuse 文件系统，当第一个 basedir 中查找文件失败时，fuse 文件系统会触发下载动作，并保存在第一个目录中供以后查找使用。这里有许多有趣的可能性。

到目前为止，除了 Bagas Sanjaya 建议的一些文档改动外，没有什么其他的 review 意见。然而，composefs 提供的设施似乎很有用，它建立在 fs-verity 的基础上，经过一段时间的磨合，该功能已经放到内核中了。在 OSTree 中支持 composefs 的工作也在进行中，但是在文件系统进入内核之前，存在着一些鸡生蛋蛋生鸡的问题。如果运气好，并且后续没有出现对 composefs 的严重反对意见，那么这个问题可能就会被解决，甚至可能在明年年初就有可能合入。

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

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

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