From: Eric Curtin <ericcurtin17@gmail.com>
To: Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>
Cc: Jan Kara <jack@suse.cz>, Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Eric Biggers <ebiggers@kernel.org>,
"Theodore Y . Ts'o" <tytso@mit.edu>, Gao Xiang <xiang@kernel.org>,
Chao Yu <chao@kernel.org>,
fsverity@lists.linux.dev, linux-erofs@lists.ozlabs.org,
linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
Eric Curtin <ericcurtin17@gmail.com>
Subject: [RFC PATCH v2 0/4] init: boot image-based systems without an initramfs (rootimage=)
Date: Mon, 27 Jul 2026 11:48:41 +0100 [thread overview]
Message-ID: <20260727104845.2607444-1-ericcurtin17@gmail.com> (raw)
In-Reply-To: <20260727-gepaukt-eislauf-waran-7c03f0e47609@brauner>
Changes since v1 (https://lore.kernel.org/all/20260718191551.1703670-1-ericcurtin17@gmail.com/),
following Christian Brauner's review
(https://lore.kernel.org/all/20260727-gepaukt-eislauf-waran-7c03f0e47609@brauner/):
The goal is unchanged: A/B image updates from a single partition,
without paying for a second userspace spin-up at boot. What changed is
how rootimage=/rootimageverity= get from "here is a path" to "here is
the verified, mounted root", which is what most of the v1 review was
about.
- Patches 1-2 are new: they add generic, reusable VFS infrastructure
(struct fs_context::source_file, path_mount_file()/
init_mount_file(), vfs_parse_fs_param_file()) that lets an in-kernel
caller hand a filesystem an already-open struct file as its mount
source instead of a path, and convert erofs's existing file-backed
mount support to use it when given. This is the "new infrastructure
available to any fs" asked for, so that init/do_mounts.c never has
to independently re-resolve a path that something else already
opened and validated.
- Patch 3 (rootimage=) now opens the image file exactly once and
mounts that same struct file via the above, instead of opening it,
doing nothing with the open, and separately handing erofs a path
that it re-resolved on its own with no guaranteed relationship to
what was checked - which is what v1 did, and which is where most of
the "second lookup" / "weak assumptions" findings came from. There
is no fd-vs-path race left because there is no second lookup left.
rootimagesrcdir= is now mandatory (rootimagesrcdir=none opts out
explicitly) instead of silently detaching the carrier by default,
so there's no more zombie superblock/dangling mountpoint by
default; you have to ask for that outcome by name.
- Patch 4 (rootimageverity=) is mostly unchanged in what it checks,
but now runs on the exact file patch 3 mounts, so the digest check
and the mount are guaranteed to agree on what "the image" is. It
also now refuses rootimageverity= together with rootimageflags=
containing device= (multi-device erofs images), since the digest
only ever covers the primary image file and silently ignoring the
rest would be a false sense of integrity.
Not changed / not attempting to fix in this version, per the v1
discussion:
- The carrier filesystem itself is still fully parsed (superblock,
directory entries, extents) before rootimageverity= gets to check
anything, since reaching the image file at all requires that. This
is structural to a file-backed image sitting on a general-purpose
writable filesystem, the same way a dm-verity root still needs a
trusted block layer under it; rootimage=/rootimageverity= are meant
to sit on top of an already-appropriately-trusted carrier (e.g.
itself dm-verity/LUKS-backed, or a well-audited always-read-only
fs), not conjure trust in an arbitrary writable one out of thin air.
- A/B slot selection and fallback/rollback bookkeeping are still the
bootloader's job, exactly as with dm-mod.create= today; this series
only does the "resolve the one path the bootloader already chose,
verify it, make it root" mechanical step for the file-backed case,
not image-based deployment policy in general.
- There is still no sysfs equivalent of
/sys/block/loopX/loop/backing_file to discover which file backs the
root after boot (the mandatory rootimagesrcdir= at least means the
carrier itself stays reachable). This would need its own generic
piece of infrastructure and is left for a follow-up.
Eric Curtin (4):
fs: allow in-kernel mounters to hand filesystems an already-open
source file
erofs: use fs_context source_file for file-backed mounts when given
init: support mounting the root filesystem from an image file
init: support pinning the root image's fsverity digest
.../admin-guide/kernel-parameters.txt | 56 ++++
Documentation/filesystems/mount_api.rst | 18 ++
fs/erofs/super.c | 19 ++
fs/fs_context.c | 39 ++-
fs/init.c | 18 ++
fs/internal.h | 2 +
fs/namespace.c | 96 ++++++-
include/linux/fs_context.h | 4 +
include/linux/init_syscalls.h | 2 +
init/do_mounts.c | 269 +++++++++++++++++-
10 files changed, 514 insertions(+), 9 deletions(-)
--
2.43.0
next prev parent reply other threads:[~2026-07-27 10:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-18 19:15 [RFC PATCH 0/2] init: boot image-based systems without an initramfs (rootimage=) Eric Curtin
2026-07-18 19:15 ` [RFC PATCH 1/2] init: support mounting the root filesystem from an image file Eric Curtin
2026-07-18 19:15 ` [RFC PATCH 2/2] init: support pinning the root image's fsverity digest Eric Curtin
2026-07-27 8:55 ` [RFC PATCH 0/2] init: boot image-based systems without an initramfs (rootimage=) Christian Brauner
2026-07-27 10:31 ` Eric Curtin
2026-07-27 10:48 ` Eric Curtin [this message]
2026-07-27 10:48 ` [RFC PATCH v2 1/4] fs: allow in-kernel mounters to hand filesystems an already-open source file Eric Curtin
2026-07-27 10:48 ` [RFC PATCH v2 2/4] erofs: use fs_context source_file for file-backed mounts when given Eric Curtin
2026-07-27 10:48 ` [RFC PATCH v2 3/4] init: support mounting the root filesystem from an image file Eric Curtin
2026-07-27 10:48 ` [RFC PATCH v2 4/4] init: support pinning the root image's fsverity digest Eric Curtin
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=20260727104845.2607444-1-ericcurtin17@gmail.com \
--to=ericcurtin17@gmail.com \
--cc=brauner@kernel.org \
--cc=chao@kernel.org \
--cc=corbet@lwn.net \
--cc=ebiggers@kernel.org \
--cc=fsverity@lists.linux.dev \
--cc=jack@suse.cz \
--cc=linux-doc@vger.kernel.org \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
--cc=xiang@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.