[RFC PATCH 0/2] init: boot image-based systems without an initramfs (rootimage=)

[Eric Curtin <ericcurtin17@gmail.com>]

Image-based Linux systems (bootc-style OS updaters, ChromeOS/Android-like
A/B schemes, embedded appliances) keep one or more immutable root
filesystem images as sealed files on a writable filesystem and pick one
at boot.  Booting such a system today always requires an initramfs, even
when that initramfs has nothing else to do; its only jobs are to parse
the kernel command line, mount the state filesystem, verify the image,
loop-mount it and switch_root into it.

This series teaches the kernel to do all of that directly:

  root=PARTUUID=... rootimage=/deploy/a/root.erofs rootimagefstype=erofs \
      rootimageverity=sha256:a9548f4c... rootimagesrcdir=/var/state

Patch 1 adds rootimage= (plus rootimagefstype=/rootimageflags=/
rootimagesrcdir=): root= then merely names the "carrier" filesystem.
The image file on it is mounted read-only through the filesystem's
file-backed mount support (available in erofs since v6.12), so no loop
device is involved, and it becomes the root that prepare_namespace()
pivots into.  The carrier mount is detached by default, or moved to
rootimagesrcdir= inside the new root, which image-based systems
practically always want since the carrier holds their writable state.

Patch 2 adds rootimageverity=, which requires the image to carry a
specific fsverity file digest, reusing the fsverity_get_digest()
interface that IMA and overlayfs already use for digest pinning.  With
a signed or measured command line (e.g. a unified kernel image), the
chain of trust extends to every byte of the root filesystem with no
userspace boot stage: the pinned digest authenticates the image's
Merkle tree root, and fsverity keeps verifying reads against it at
runtime, so later tampering with the carrier is caught as well.

This is the file-backed analogue of dm-mod.create= (CONFIG_DM_INIT),
which moved the equivalent block-device setup out of the initramfs for
verity-partition layouts back in v5.1.  For file-based deployment
layouts nothing similar exists, so distributions ship a dracut stack
whose only purpose is the five steps above, and which remains the
largest and most failure-prone moving part of an otherwise fully
image-defined boot.

Tested on arm64 (qemu -M virt with KVM), with no initrd= at any point:

 - control: plain ext4 root boots as before
 - rootimage=: an erofs image file on ext4 is mounted as /, the carrier
   ends up on /var/state, PID 1 runs from the image ~0.18s after kernel
   entry
 - rootimageverity= with the correct digest: boots, digest logged
 - rootimageverity= with a wrong digest: panics with expected-vs-got
 - build: defconfig and allnoconfig (!CONFIG_FS_VERITY, !CONFIG_BLOCK),
   both with W=1, no warnings

Open questions for review:

 - Should the carrier always be detached, dropping rootimagesrcdir=?
   The image mount pins the carrier superblock either way, so userspace
   can re-mount it, but a conflicting ro/rw state then needs a remount
   dance.
 - Should this be behind a Kconfig option like CONFIG_DM_INIT is?  All
   added code is __init and freed after boot.
 - Naming: rootimage= vs. extending root= syntax (e.g. root=image:...).

This series was developed with AI assistance (see the Assisted-by tags
and Documentation/process/coding-assistants.rst).

Eric Curtin (2):
  init: support mounting the root filesystem from an image file
  init: support pinning the root image's fsverity digest

 .../admin-guide/kernel-parameters.txt         |  42 ++++
 init/do_mounts.c                              | 221 ++++++++++++++++--
 2 files changed, 250 insertions(+), 13 deletions(-)

-- 
2.43.0