linux-kernel - Re: [PATCH] initrd: support erofs as initrd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <198f1915a27.10415eef562419.6441525173245870022@zohomail.com>
Date: Thu, 28 Aug 2025 20:44:51 +0400
From: Askar Safin <safinaskar@...omail.com>
To: "Gao Xiang" <hsiangkao@...ux.alibaba.com>
Cc: "Byron Stanoszek" <gandalf@...ds.org>, "Christoph Hellwig" <hch@....de>,
	"gregkh" <gregkh@...uxfoundation.org>,
	"julian.stecklina" <julian.stecklina@...erus-technology.de>,
	"linux-fsdevel" <linux-fsdevel@...r.kernel.org>,
	"linux-kernel" <linux-kernel@...r.kernel.org>,
	"rafael" <rafael@...nel.org>,
	"torvalds" <torvalds@...ux-foundation.org>,
	"viro" <viro@...iv.linux.org.uk>,
	"Thomas Weißschuh" <thomas.weissschuh@...utronix.de>,
	"Christian Brauner" <brauner@...nel.org>
Subject: Re: [PATCH] initrd: support erofs as initrd

 ---- On Wed, 27 Aug 2025 13:58:02 +0400  Gao Xiang <hsiangkao@...ux.alibaba.com> wrote --- 
 > The additional cpio extraction destroys bit-for-bit identical data
 > protection, or some other new verification approach is needed for
 > initramfs tmpfs.

Put erofs to initramfs and sign whole thing.

Also: initramfs's are concatenatable.
So, you can put erofs to cpio and sign the result.
And then concatenate that cpio with another cpio (with init).

Also, you can put erofs to cpio, then sign this thing, and then add init to kernel
built-in cpio (via INITRAMFS_SOURCE).

In fact, this built-in initramfs (INITRAMFS_SOURCE) is very powerful thing.
You can specify there arbitrary boot logic, and have that initramfs inside kernel
image.

You can even specify logic there for checking signature of erofs (not cpio, but erofs itself).

Also, if all these is still not helpful, then try to describe your use case in more details.
I still don't understand what is wrong with signing cpio, which contains erofs.
Yes, this will slightly complicate pipeline for building erofs. Now you will
have to put it to cpio and then sign that cpio. So what?

Also, if your users want to have their own init inside that erofs, then
you can just write trivial init, which calls their init.
And you can put that trivial init to cpio, which is build-in in kernel via INITRAMFS_SOURCE.

Also, when I hear "sign, signature, something something", then UKIs show up in my mind.
( https://uapi-group.org/specifications/specs/unified_kernel_image/ ).
Maybe they are somehow helpful? That page talks a lot about signatures, measuring into
TPM, etc. (Every time that page says "initrd", they mean initramfs, of course.)

-- 
Askar Safin
https://types.pl/@safinaskar