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. 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. * It sets whatever xattrs the archive comes with through vfs_setxattr() during early boot. Which is insane. 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. * 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]). 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. [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
