Re: [PATCH v2 0/4] fs: add immutable rootfs

[Jeff Layton <jlayton@kernel.org>]

On Mon, 2026-01-12 at 16:47 +0100, Christian Brauner wrote:
> Currently pivot_root() doesn't work on the real rootfs because it
> cannot be unmounted. Userspace has to do a recursive removal of the
> initramfs contents manually before continuing the boot.
> 
> Really all we want from the real rootfs is to serve as the parent mount
> for anything that is actually useful such as the tmpfs or ramfs for
> initramfs unpacking or the rootfs itself. There's no need for the real
> rootfs to actually be anything meaningful or useful. Add a immutable
> rootfs called "nullfs" that can be selected via the "nullfs_rootfs"
> kernel command line option.
> 
> The kernel will mount a tmpfs/ramfs on top of it, unpack the initramfs
> and fire up userspace which mounts the rootfs and can then just do:
> 
>   chdir(rootfs);
>   pivot_root(".", ".");
>   umount2(".", MNT_DETACH);
> 
> and be done with it. (Ofc, userspace can also choose to retain the
> initramfs contents by using something like pivot_root(".", "/initramfs")
> without unmounting it.)
> 
> Technically this also means that the rootfs mount in unprivileged
> namespaces doesn't need to become MNT_LOCKED anymore as it's guaranteed
> that the immutable rootfs remains permanently empty so there cannot be
> anything revealed by unmounting the covering mount.
> 
> In the future this will also allow us to create completely empty mount
> namespaces without risking to leak anything.
> 
> systemd already handles this all correctly as it tries to pivot_root()
> first and falls back to MS_MOVE only when that fails.
> 
> This goes back to various discussion in previous years and a LPC 2024
> presentation about this very topic.
> 
> Now in vfs-7.0.nullfs.
> 
> Signed-off-by: Christian Brauner <brauner@kernel.org>
> ---
> Changes in v2:
> - Rename to "nullfs".
> - Update documentation.
> - Link to v1: https://patch.msgid.link/20260102-work-immutable-rootfs-v1-0-f2073b2d1602@kernel.org
> 
> ---
> Christian Brauner (4):
>       fs: ensure that internal tmpfs mount gets mount id zero
>       fs: add init_pivot_root()
>       fs: add immutable rootfs
>       docs: mention nullfs
> 
>  .../filesystems/ramfs-rootfs-initramfs.rst         |  32 +++-
>  fs/Makefile                                        |   2 +-
>  fs/init.c                                          |  17 ++
>  fs/internal.h                                      |   1 +
>  fs/mount.h                                         |   1 +
>  fs/namespace.c                                     | 181 ++++++++++++++-------
>  fs/nullfs.c                                        |  70 ++++++++
>  include/linux/init_syscalls.h                      |   1 +
>  include/uapi/linux/magic.h                         |   1 +
>  init/do_mounts.c                                   |  14 ++
>  init/do_mounts.h                                   |   1 +
>  11 files changed, 254 insertions(+), 67 deletions(-)
> ---
> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> change-id: 20260102-work-immutable-rootfs-b5f23e0f5a27

I like the set overall. My only real gripe is the new command-line
option. Won't that make distro adoption hard?

IIUC, with this new method, you're just adding a new nullfs at the
bottom of the stack and then mounting the traditional ramfs as the
mutable rootfs on top of it.

Would there be any harm in just always doing this (and dropping the
command-line option)?

You would end up "leaking" both the nullfs and ramfs in the case of
traditional userspace that was unaware of the extra mount, but that
seems like it should be something we could live with.
-- 
Jeff Layton <jlayton@kernel.org>