On Wed, 2026-11-11 at 14:45 +0100, Roberto Sassu wrote:
> On Tue, 2026-11-10 at 17:21 +0100, Christian Brauner wrote:
> > On Thu, Nov 05, 2026 at 11:37:39AM -0800, Danny Hu wrote:
> > > This proposal consists in including file metadata as additional files
> > > named
> > > METADATA!!!, for each file added to the ram disk. The CPIO parser in the
> > > kernel recognizes these special files from the file name, and calls the
> > > appropriate parser to add metadata to the previously extracted file.
> >
> > No, sorry. We're not going to do this:
> >
> > * This is in-band signalling by filename. A METADATA!!! entry changes
> > the meaning of whatever came before it in the stream.
>
> Yes, it is a hack, but such an image is backward compatible with
> previous versions. There is no new format, version bump, etc.
>
> > Which is just the TRAILER!!! nonsense all over again (cf. [1]).
> > No cpio tool knows about it and a kernel without this parser silently
> > extracts the metadata as junk files.
>
> METADATA!!! is stored in ramfs/tmpfs if not processed, so it is just a
> temporary file, like the rest of the initramfs content.
>
> > * It sets whatever xattrs the archive comes with through vfs_setxattr()
> > during early boot. Which is insane.
>
> Similarly, the archive can already ship arbitrary binaries that get
> executed as root. If you want, we could restrict it to security.ima and
> security.evm only.
>
> > Not just security.ima but security.capability, security.selinux,
> > trusted.* and anything else.
> >
> > And we've NAKed this before in 2018 (cf. [2]).
> > The magic file name scheme was called a kludge back then too (cf. [3]).
> > Nothing about that has changed.
> >
> > * The initrd is already covered as a whole. Appraising
> > individual files inside an image whose integrity is plain weird.
>
> I agree when the image is prebuilt and has a known reference value. As
> far as I know, there is no reference value when the initial ram disk is
> dynamically generated on the host. In the latter case, using finer-
> granularity measurement/appraisal is the only option.
>
>
> > * If kernel and initrd are owned by different parties this can be
> > done in userspace. A trusted /init can apply xattrs from a manifest
> > before it runs anything else. That was pointed out in 2019 already
> > (cf. [4], [5], [6]).
>
> Unless the trusted /init is in the kernel image and launched as User-
> Mode-Driver (UMD), you need to measure/appraise it, which again
> requires its signature to be carried in the initial ram disk.
>
>
> > This has been proposed in some form since 2018 and never found a
> > maintainer willing to take it. I'm not taking a private cpio extension
> > into init/initramfs.c either.
>
> I understand. v3 was close to being upstreamed but then got stuck
> because nobody was willing to take it, despite all review comments
> being addressed. In its favor, this extension is harmless. If
> METADATA!!! is not there, nothing happens. If it is there and not
> supported, it is a junk file removed together with the rest of the
> initramfs content.
At the time, there was no initramfs maintainer. At LSF/MM 2018, I brought it up
[1]. AL said he wasn't the maintainer (and if I touched it, I would become the
de facto maintainer).
[1] https://lwn.net/Articles/753276/
Mimi
> > [1]:
> > https://lore.kernel.org/r/[email protected]
> > [2]:
> > https://lore.kernel.org/r/[email protected]
> > [3]:
> > https://lore.kernel.org/r/[email protected]
> > [4]:
> > https://lore.kernel.org/r/[email protected]
> > [5]: https://lore.kernel.org/r/[email protected]
> > [6]:
> > https://lore.kernel.org/r/calcetrv3b205l38xqpr6qqwgn6-vxqdpojguygjjpgm-jqq...@mail.gmail.com
> >
>
