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

[Roberto Sassu <roberto.sassu@huaweicloud.com>]

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.

Roberto

> [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
>