在即将发布的 Linux 7.0 内核中，最引入注目的早期合并之一便是 nullfs。
什么是 nullfs？
简单来说，nullfs 是一个绝对为空的文件系统，它不支持创建任何文件，也不存储任何数据。你可能会问：内核里加入一个"一无用处"的文件系统到底图什么？
事实上，nullfs 的引入是为了解决 Linux 启动过程中困扰开发者多年的"优雅性"问题，并为内核安全性（Hardening）打下基础。
1. 破解 pivot_root 的历史遗留困局
在 Linux 引导过程中，定位并挂载根文件系统（rootfs）是一项极其复杂的任务。这通常涉及解析配置文件、组建 RAID 卷、甚至通过网络获取数据。
为了完成这些操作，内核首先会挂载一个临时的根文件系统------initramfs。它随内核镜像一起加载，包含必要的驱动和工具。
传统方案的"不优雅"之处
按照标准逻辑，当真正的磁盘文件系统准备好后，我们应该使用 pivot_root() 系统调用将临时根替换为永久根。但问题在于：rootfs（初始 ramfs）无法被 pivot_root()。
当前的通用做法（如 switch_root 脚本）包含以下繁琐步骤：
-
删除 initramfs 中的所有文件以释放内存。
-
在 initramfs 之上"覆盖挂载"（Overmount）新根。
-
将标准输入/输出/错误重定向到新终端。
-
执行新的
init进程。
nullfs 的降维打击
在 7.0 中，内核将整个文件系统树建立在 nullfs 之上。
-
新逻辑： 临时根和永久根都挂载在 nullfs 这个"空基座"上。
-
结果： 由于 nullfs 才是真正的底层基座，
pivot_root()终于可以正常工作，将永久根直接置于挂载栈下方并卸载临时根。整个过程更加原生、简洁。
2. 内核线程隔离：填补安全鸿沟
除了简化挂载流程，nullfs 的另一个大招是增强内核线程（Kernel Threads）的隔离性。
共享 fs_struct 的风险
在 Linux 系统中，最早创建的两个进程是 init（用户态祖先）和 kthreadd（内核态祖先）。
以往，这两个进程共享同一个初始 fs_struct（文件系统结构表）。这意味着：
-
每一个内核线程（如
[rcu_tasks_rude_kthread]）理论上都拥有与init进程相同的文件系统访问上下文。 -
虽然它们互相信任，但这种"全开放"的设计在面对潜在 Bug 或恶意利用时显得弱不禁风。
nullfs 带来的硬化方案
由 Christian Brauner 提出的方案是：让内核线程运行在 nullfs 实例中。
-
彻底断链： 内核线程的根目录被设置为 nullfs。由于 nullfs 无法存放文件，内核线程默认失去对文件系统的所有访问权限。
-
按需授权： 只有确实需要访问文件系统的线程（如处理固件加载、Core Dump 或 Unix 域套接字的线程），才通过新引入的
scoped_with_init_fs()宏临时获得权限。// 只有在作用域内，内核线程才具备文件系统访问能力
scoped_with_init_fs() {
/* 执行必要的文件系统操作，如加载固件 */
}
这种"最小权限原则"显著提升了内核的稳健性，防止内核线程意外干扰用户态的 init 进程。
3. 开发者心声：虽然疯狂，但它能跑
这项改动触及了内核最底层的逻辑，其实现者 Christian Brauner 对此表现得非常坦诚：
"这主意疯吗？疯。可能会出 Bug 吗？极有可能。但它至少能跑（It boots）。"
尽管改动巨大且充满挑战，但社区对此方向普遍持支持态度。这种对深层代码的重构，标志着 Linux 在追求更现代、更安全的架构上从未停步。
总结
nullfs 的引入不仅仅是增加了一个文件系统类型，它是对 Linux 引导架构的一次微调，更是对内核线程安全边界的一次重划。
