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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox