Re: [PATCH v6 0/4] initramfs: add support for xattrs in the initial ram disk

[Mimi Zohar <zohar@linux.ibm.com>]

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/d69f329c-8365-bb0e-69ee-774cbea141b2@zytor.com
> > [2]: https://lore.kernel.org/r/3d1bfbd7-7d45-4cf1-32d6-7f6985b42393@schaufler-ca.com
> > [3]: https://lore.kernel.org/r/f2886ac7-aff9-94bc-5f65-b3b2e946a6ff@schaufler-ca.com
> > [4]: https://lore.kernel.org/r/20190512091748.s6fvy2f5p2a2o6ja@isilmar-4.linta.de
> > [5]: https://lore.kernel.org/r/20190512194322.GA71658@rani.riverdale.lan
> > [6]: https://lore.kernel.org/r/CALCETrV3b205L38xqPr6QqwGn6-vxQdPoJGUygJJpgM-JqqXfQ@mail.gmail.com
> > 
>