From: Christian Brauner <brauner@kernel.org>
To: linux-fsdevel@vger.kernel.org
Cc: "Alexander Viro" <viro@zeniv.linux.org.uk>,
"Jan Kara" <jack@suse.cz>, "Jeff Layton" <jlayton@kernel.org>,
"Amir Goldstein" <amir73il@gmail.com>,
"Lennart Poettering" <lennart@poettering.net>,
"Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl>,
"Josef Bacik" <josef@toxicpanda.com>,
"Christian Brauner" <brauner@kernel.org>,
stable@vger.kernel.org
Subject: [PATCH v2 0/4] fs: add immutable rootfs
Date: Mon, 12 Jan 2026 16:47:07 +0100 [thread overview]
Message-ID: <20260112-work-immutable-rootfs-v2-0-88dd1c34a204@kernel.org> (raw)
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
next reply other threads:[~2026-01-12 15:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-12 15:47 Christian Brauner [this message]
2026-01-12 15:47 ` [PATCH v2 1/4] fs: ensure that internal tmpfs mount gets mount id zero Christian Brauner
2026-01-12 19:37 ` Jeff Layton
2026-01-12 15:47 ` [PATCH v2 2/4] fs: add init_pivot_root() Christian Brauner
2026-01-12 15:47 ` [PATCH v2 3/4] fs: add immutable rootfs Christian Brauner
2026-01-12 15:47 ` [PATCH v2 4/4] docs: mention nullfs Christian Brauner
2026-01-13 14:17 ` [PATCH v2 0/4] fs: add immutable rootfs Jeff Layton
2026-01-14 8:58 ` Christian Brauner
2026-01-14 10:32 ` [RFC PATCH 5/4] fs: use nullfs unconditionally as the real rootfs Christian Brauner
2026-01-14 12:05 ` Jeff Layton
2026-01-14 11:58 ` [PATCH v2 0/4] fs: add immutable rootfs Jeff Layton
2026-01-25 19:18 ` Askar Safin
2026-02-01 19:55 ` Askar Safin
2026-02-04 13:00 ` Christian Brauner
2026-02-04 14:48 ` Askar Safin
2026-02-02 14:27 ` Askar Safin
2026-02-02 16:22 ` Askar Safin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260112-work-immutable-rootfs-v2-0-88dd1c34a204@kernel.org \
--to=brauner@kernel.org \
--cc=amir73il@gmail.com \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=josef@toxicpanda.com \
--cc=lennart@poettering.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=zbyszek@in.waw.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox