LWN：丢弃文件系统的page cache！

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

Dropping the page cache for filesystems

By Jake Edge
June 11, 2024
LSFMM+BPF
Gemini-1.5-flash translation
https://lwn.net/Articles/977486/

VFS 维护者 Christian Brauner 在 2024 年的 Linux 存储、文件系统、内存管理和 BPF 峰会 上主持了一场讨论，主题是是否可以有选择地丢弃文件系统在页面缓存(page cache)中的内容。正如他在 主题提案(topic proposal) 中描述的，让他走上这条道路的用例来自 GNOME，GNOME 希望能够安全地暂停对加密主目录的访问。虽然内核开发人员都知道这一点，但令其他人惊讶的是，如果要读取的数据仍然存在于页面缓存中，则读取已暂停的加密文件系统将成功。

Secrets 泄露

Brauner 通过快速描述测试用例开始本次讨论，该测试用例重现了问题，他将其包含在自己的提案（以及他的 幻灯片 中）。它创建一个镜像文件，使用 LUKS cryptsetup 工具 将其转换为加密卷，在其上创建 XFS 文件系统，并将其挂载。下一步是将字符串 "secrets" 写入文件系统上的一个文件，并使用 luksSuspend 操作来暂停加密块设备——对文件进行简单的 cat 仍然会显示秘密数据。

他询问是否有一种方法可以添加一个 API 来丢弃页面缓存的内容，从而让文件 read 动作产生错误。他列出了在主题提案线程中发布的反对意见（以及其他想法），他已将这些意见收集到一张幻灯片上。

在邮件列表中，Jan Kara 指出了页面缓存中被引用的 folio 的问题，这些 folio 可能来自 vmsplice() 调用；这些页面无法被丢弃。Kara 还询问了页面缓存丢弃操作与 mlock() 的交互，并 指出 映射可执行代码的页面 "实际上是不可以驱逐（unevictable）的"。除此之外，如果目的是防御 冷启动攻击，则需要 将内存清零，因为丢弃页面缓存条目不会改变内存内容，Kara 补充道。

Matthew Wilcox 建议 使用 security_file_permission() 钩子来禁止 Linux 安全模块 (LSM) 读取数据。因此比如说可以用一个新的 BPF LSM 程序在执行暂停操作时被调用，以对任何读取操作返回错误，Brauner 说。他认为考虑某种类型的 API 来进行页面缓存丢弃对于其他用例（不仅仅是冷启动保护）是有价值的。例如，David Howells 告诉他，他会将这种 API 用于 AFS；systemd 也可能有一个用例，所以至少值得考虑添加它。

Amir Goldstein 说，Linux 测试项目 (LTP) 中有一些测试目前正在进行 "一些体操动作" 以尝试丢弃文件系统的页面缓存；然而，它并不可靠，因此 API 对测试也很有用。Jeff Layton 指出，Trond Myklebust 已经发布了针对 NFS 的补丁，这些补丁将丢弃单个 inode 的页面缓存，这可能会提供部分解决方案。Brauner 说，Kent Overstreet 提到了 bcachefs 中子卷删除的类似功能。Dave Chinner 指出，posix_fadvise() 已经可以丢弃特定 inode 的页面缓存。

愚蠢的想法？

"你可以说这是一个愚蠢的想法"，Brauner 笑着说。Layton 不同意，他说它很有用。Wilcox 同意这一点："我可以看到用例，它是有意义的，这是人们想要做的一件合理的事情，只是实现起来比较困难"。他说，可以通过将这些页面标记为 "未更新" 并将其清零来处理 vmsplice() 和 mlock() 。但对于已经被移交给 RDMA 驱动程序的页面（RDMA 驱动程序维护着这些页面的状态），它就 "非常棘手"。

"可以直接失败报错吗？"，Brauner 问；如果无法完全完成操作，也许它可以返回错误。Wilcox 说，可能 99% 的页面可以在不遇到任何极端情况的情况下被丢弃。

Ted Ts'o 说，也许问题的一部分在于该功能最初被引入作为一项安全功能，这使得开发人员立即专注于极端情况。Fscrypt 具有 "尽力而为" 机制，该机制尝试在密钥从密钥环中移除时移除所有目录条目并刷新所有 inode。没有努力处理加密文件仍然打开的可能性，因为该功能最初针对的是 ChromeOS，它只在用户会话结束之后才会发生。它不是一个完整的解决方案，也没有作为一项功能进行宣传，也没有进行记录。

他说，这是该功能的一种可能的向前路径，但如果需要尝试处理所有极端情况，那么这样做将很困难。Wilcox 说，如果你需要确保文件系统上的 LibreOffice 文档不再可访问，这将非常简单，但如果你想为文件系统上的每个文件都保证这一点，那么就会困难得多。

Overstreet 说，这是 "又一次 revoke() 讨论"，这个问题确实需要在某个时刻得到解决。revoke() 系统调用 已经成为文件系统领域中十多年来的一个话题（至少）；它旨在关闭给定文件的所有已打开的文件描述符，但它在无数的极端情况下遇到了阻碍。Overstreet 说，在多个地方需要使用 revoke() （ fsck 在特殊情况下，也就是 debugfs），因此应该有人来解决这个问题。Kara 说，他不愿意为丢弃页面缓存提供保证，因为它很大程度上取决于文件系统使用方式的上下文，但在许多情况下，它应该可以正常工作。

Systemd 使用

Lennart Poettering 说，systemd 希望使用此功能，类似于 fscrypt 的使用方式。尽力而为的解决方案是可以接受的，但他希望在失败时得到某种错误指示；文件系统应该尝试从缓存中丢弃尽可能多的页面，并且可能报告无法丢弃的页面数量。systemd 将使用 cgroup 接口在调用操作之前冻结用户会话，这应该可以减少极端情况问题。他说，systemd 的用例不应该与冷启动保护用例混淆，在冷启动保护用例中，加密设备需要暂停，并且需要将页面清零，这超出了 systemd（以及其他）需要的范围。

Ts'o 说，fscrypt 报告了它无法驱逐的 inode 数量。它输出一个包含该数量和一个 inode 编号的日志消息作为示例；这些信息主要供 ChromeOS 开发人员用于调试。它是 "半途而废的，但这就是我们所做的"。

Chinner 说，当进行此页面缓存删除时，存在一个问题，即如何处理需要写入的脏页面。它们会被丢弃，还是操作会等待写入完成？写入错误将在哪里报告？Brauner 说，人们认为设备已经暂停，因此不会有任何脏页面。Ts'o 说，当密钥被移除时，fscrypt 会写入所有脏 inode，因为它在密钥移除后将无法写入。如果用户空间已暂停（如 systemd 的用例），则没有任何人可以报告任何错误，因此只能在控制台中输出消息。

Chinner 说，重要的是要向任何新 API 的用户明确说明，他们有责任在丢弃其页面缓存之前确保文件系统已冻结。例如，对于将可执行文件映射到内存的文件系统，丢弃其页面缓存将无法正常工作。但 Wilcox 说，这些不是人们想要用这种功能来保护的文件类型；人们担心的是文档文件和网络浏览器历史记录。Brauner 说，该功能将针对系统级软件，这些软件被假定为知道自己在做什么；Wilcox 说，99% 的解决方案将提高所有人的安全性，但重要的是不要声称它是一个 100% 的解决方案。

Goldstein 有些担心 inode 缓存；只有文件数据是关注点，还是应该对元数据也提供保护？Chinner 说，在文件系统冻结时尝试清除 inode 缓存会导致死锁。Wilcox 说，应该清除目录条目缓存，但他认为不需要清除 inode 缓存；然而，Chinner 说，这仍然会导致死锁。

Ts'o 指出，fscrypt 使用的顺序是：清除所有目录条目，缩小 inode 缓存，执行任何必要的写入，然后冻结文件系统并清除页面缓存；这是执行这些操作的正确顺序，但所有这些都只是尽力而为。他建议，也许 luksSuspend 操作可以添加一些额外的步骤，因为暂停加密设备通常会从内存中删除这些额外数据中获益。

Shrinkers

Chinner 说，目前用于清除目录条目和 inode 缓存的机制是 收缩器（shrinkers），但没有办法将它们限制在单个超级块（superblock）内；此外，这些缓存按内存控制组进行分区，因此任何清除操作都需要考虑这些因素。Wilcox 说，卸载操作显然会清除所有这些信息，因此也许可以使用这种方法。但 Chinner 说，这对于此用例不可行，因为用户正在将系统 suspend to RAM，并且用户空间应用程序正在运行；umount 动作会破坏所有这些。

Overstreet 说，该功能可以与实时文件系统迁移的想法很好地结合。Bcachefs 开发人员正在准备为该文件系统发布同步发送和接收功能（synchronous send and receive），因此将该功能与页面缓存刷新/丢弃操作相结合，将能够将容器及其文件系统实时迁移到另一个主机。Overstreet 澄清说，他谈论的是与 Btrfs 发送和接收 相同的想法。

有些人讨论了按每个超级块的范围来清理缓存的用例，尽管有些人认为这是一个难题。Chinner 说，收缩器接口可以被使用，并添加每个超级块的功能；这并不难，因为清理机制的大部分已经在那里完成。他一直在研究使用收缩器作为实现丢弃缓存的方法，因为现有方法（使用 /proc/sys/vm/drop_caches) 需要很长时间。他说，它作为一个单独的线程运行，因此对于大型缓存（"有几亿个缓存的 inode"），它可能需要长达 15 分钟才能运行，这对基准测试和其他用途来说是有问题的。

Kara 询问收缩器是否是一个合适的接口，或者是否基于卸载时所做的操作会有更好的接口。存在一个固有问题，即收缩器专注于内存回收，而不是此功能所需的任务。他认为可能需要一个新的接口，这个接口会更 "理智"。Chinner 承认，除了收缩器所做的工作之外，还有更多工作要做，但他认为收缩器可能是解决方案的一部分。

Luis Chamberlain 询问，为什么这种新机制不会在每次文件系统冻结时使用。Chinner 说，文件系统通常为了备份目的而被冻结，因此页面缓存条目仍然很重要。有人讨论了 API，以及它是否应该是一个 ioctl() 命令或其他东西。Chinner 认为，最好是一些新的 API（可能是通过系统调用）不会与文件系统冻结或其他任何操作绑定，这可能是正确的前进方向；如果内部需要更改，这将提供最大的灵活性。

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

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

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