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

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

[Christian Brauner]

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

[PATCH v2 1/4] fs: ensure that internal tmpfs mount gets mount id zero

[Christian Brauner]

and the rootfs get mount id one as it always has. Before we actually
mount the rootfs we create an internal tmpfs mount which has mount id
zero but is never exposed anywhere. Continue that "tradition".

Fixes: 7f9bfafc5f49 ("fs: use xarray for old mount id")
Cc: <stable@vger.kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
---
 fs/namespace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index c58674a20cad..8b082b1de7f3 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -221,7 +221,7 @@ static int mnt_alloc_id(struct mount *mnt)
 	int res;
 
 	xa_lock(&mnt_id_xa);
-	res = __xa_alloc(&mnt_id_xa, &mnt->mnt_id, mnt, XA_LIMIT(1, INT_MAX), GFP_KERNEL);
+	res = __xa_alloc(&mnt_id_xa, &mnt->mnt_id, mnt, xa_limit_31b, GFP_KERNEL);
 	if (!res)
 		mnt->mnt_id_unique = ++mnt_id_ctr;
 	xa_unlock(&mnt_id_xa);

-- 
2.47.3

Re: [PATCH v2 1/4] fs: ensure that internal tmpfs mount gets mount id zero

[Jeff Layton]

On Mon, 2026-01-12 at 16:47 +0100, Christian Brauner wrote:
> and the rootfs get mount id one as it always has. Before we actually
> mount the rootfs we create an internal tmpfs mount which has mount id
> zero but is never exposed anywhere. Continue that "tradition".
> 
> Fixes: 7f9bfafc5f49 ("fs: use xarray for old mount id")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Christian Brauner <brauner@kernel.org>
> ---
>  fs/namespace.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/namespace.c b/fs/namespace.c
> index c58674a20cad..8b082b1de7f3 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -221,7 +221,7 @@ static int mnt_alloc_id(struct mount *mnt)
>  	int res;
>  
>  	xa_lock(&mnt_id_xa);
> -	res = __xa_alloc(&mnt_id_xa, &mnt->mnt_id, mnt, XA_LIMIT(1, INT_MAX), GFP_KERNEL);
> +	res = __xa_alloc(&mnt_id_xa, &mnt->mnt_id, mnt, xa_limit_31b, GFP_KERNEL);
>  	if (!res)
>  		mnt->mnt_id_unique = ++mnt_id_ctr;
>  	xa_unlock(&mnt_id_xa);

Reviewed-by: Jeff Layton <jlayton@kernel.org>

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

[Jeff Layton]

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>

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

[Christian Brauner]

On Tue, Jan 13, 2026 at 09:17:05AM -0500, Jeff Layton wrote:
> 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.

I would be open to trying to make it unconditional. IOW, a patch on top
of the current set that removes the "nullfs_rootfs" command line so that
we can simply revert if it turns out that is an issue.

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

[Jeff Layton]

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

Reviewed-by: Jeff Layton <jlayton@kernel.org>

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

[Askar Safin]

Christian Brauner <brauner@kernel.org>:
> 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

Note: this *is* possible to get access to nullfs.

In the end of this email you will find code, which proves this. I tested it
on current vfs.all. The program will print "done", and this will prove my
statement.

I think this is not a bug. I just want to make sure you are aware of this.

=====

#define GNU_SOURCE
#define _GNU_SOURCE

#include <fcntl.h>
#include <sys/mount.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <sys/stat.h>
#include <sched.h>
#include <sys/wait.h>

#define OPEN_TREE_NAMESPACE	(1 << 1)	/* Clone the target tree into a new mount namespace */

/* Get information about namespace. */
#define NS_MNT_GET_INFO _IOR(0xb7, 10, struct mnt_ns_info)

struct mnt_ns_info {
	__u32 size;
	__u32 nr_mounts;
	__u64 mnt_ns_id;
};

int
main (void)
{
    mkdir ("/foo", 0777);
    if (mount ("tmpfsfoo", "/foo", "tmpfs", 0, NULL) == -1)
        {
            fprintf (stderr, "mount\n");
            return 1;
        }
    int ns = open_tree (-EBADFD, "/foo", OPEN_TREE_NAMESPACE);
    if (ns == -1)
        {
            fprintf (stderr, "open_tree failed\n");
            return 1;
        }
    if (fork () == 0)
        {
            if (setns (ns, CLONE_NEWNS) == -1)
                {
                    abort ();
                }
            if (umount2 ("/", MNT_DETACH) == -1) // This umount2 will succeed
                {
                    abort ();
                }
            _exit (0);
        }
    {
        int status;
        if (wait (&status) == -1)
            {
                abort ();
            }
        if (status != 0)
            {
                abort ();
            }
    }
    if (fork () == 0)
        {
            if (setns (ns, CLONE_NEWNS) == -1)
                {
                    abort ();
                }
            if (umount2 ("/", MNT_DETACH) == 0) // This umount2 will fail, because we got to nullfs
                {
                    abort ();
                }
            _exit (0);
        }
    {
        int status;
        if (wait (&status) == -1)
            {
                abort ();
            }
        if (status != 0)
            {
                abort ();
            }
    }
    printf ("done\n");
    return 0;
}

-- 
Askar Safin

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

[Askar Safin]

Christian, important! Your patchset breaks userspace! (And I tested this.)

Christian Brauner <brauner@kernel.org>:
> 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.

listmount is buggy (see details below), but currently on a typical
Linux distro the bug is hidden. Your new nullfs patchset exposes the bug,
and now typical Linux configuration becomes buggy!

Look at this loop:
https://elixir.bootlin.com/linux/v6.19-rc5/source/fs/namespace.c#L5518 .

This loop is executed, when we call listmount on non-our namespace with
LSMT_ROOT.

As you can see, this loop finds mount, which is exactly one layer above
initial root mount. But why? What if our initial root mount was
overmounted multiple times?

What (in my opinion) is actually needed here is to find topmost overmount
of initial root mount. We know how to do this, we do this here:
https://elixir.bootlin.com/linux/v6.19-rc5/source/fs/namespace.c#L6096 .

Fortunately, current listmount code works in a typical configuration.
Usually we indeed overmount initramfs exactly one time.
So, listmount usually does the right thing.

But this nullfs patchset breaks listmount. Now on a typical distro
(we assume that initramfs implementations (i. e. dracut, etc) are not
yet changed to take advantage of nullfs) initial root mount (i. e. nullfs)
will be overmounted two times: initramfs and actual disk root fs.

So listmount with LSMT_ROOT in somebody's else namespace will return
initramfs instead of actual topmost root fs.

I think this listmount bug should be fixed before nullfs is applied to
mainline.

I tested listmount behavior I'm talking about. On both vfs.all (i. e. with
nullfs patches applied) and on some older vfs.git commit (without nullfs).

-- 
Askar Safin

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

[Askar Safin]

Christian Brauner <brauner@kernel.org>:
> 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.

I want to point out at yet another benefit of this nullfs patchset:
it prevents data loss on external devices.

Here is why:
https://lore.kernel.org/all/20210522113155.244796-3-dong.menglong@zte.com.cn/
(search for phrase "data lose arise").

-- 
Askar Safin

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

[Askar Safin]

Christian Brauner <brauner@kernel.org>:
> Add a immutable
> rootfs called "nullfs"

Why not fix pivot_root instead?

I. e. why not make sure pivot_root will work on true root of VFS?

-- 
Askar Safin

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

[Christian Brauner]

On Sun, Feb 01, 2026 at 10:55:31PM +0300, Askar Safin wrote:
> Christian, important! Your patchset breaks userspace! (And I tested this.)

If a bug is found in a piece of code we _calmly_ point it out and fix it.

> I tested listmount behavior I'm talking about. On both vfs.all (i. e. with
> nullfs patches applied) and on some older vfs.git commit (without nullfs).

Looking at a foreign mount namespace over which the caller is privileged
intentionally lists all mounts on top of the namespace root. In contrast
to mountinfo which always looks at another mount namespace from the
perspective of the process that is located within that mount namespace
listmount() on a foreing mount namespace looks at the namespace itself
and aims to list all mounts in that namespace. Since it is a new api
there can be no regressions.

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

[Askar Safin]

On Wed, Feb 4, 2026 at 4:01 PM Christian Brauner <brauner@kernel.org> wrote:
>
> On Sun, Feb 01, 2026 at 10:55:31PM +0300, Askar Safin wrote:
> > Christian, important! Your patchset breaks userspace! (And I tested this.)
>
> If a bug is found in a piece of code we _calmly_ point it out and fix it.

Okay, I will be calmer next time.

> > I tested listmount behavior I'm talking about. On both vfs.all (i. e. with
> > nullfs patches applied) and on some older vfs.git commit (without nullfs).
>
> Looking at a foreign mount namespace over which the caller is privileged
> intentionally lists all mounts on top of the namespace root. In contrast
> to mountinfo which always looks at another mount namespace from the
> perspective of the process that is located within that mount namespace
> listmount() on a foreing mount namespace looks at the namespace itself
> and aims to list all mounts in that namespace. Since it is a new api
> there can be no regressions.

Okay. Thank you for your explanation.

But then instead of a loop (
https://elixir.bootlin.com/linux/v6.19-rc5/source/fs/namespace.c#L5518
)
I suggest simply using ns->root->overmount.

-- 
Askar Safin