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] [day] [month] [year] [list]

Message-ID: <79315382-5ba8-42c1-ad03-5cb448b23b72@linux.alibaba.com>
Date: Fri, 29 Aug 2025 01:14:34 +0800
From: Gao Xiang <hsiangkao@...ux.alibaba.com>
To: Askar Safin <safinaskar@...omail.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 2025/8/29 01:00, Gao Xiang wrote:
> 
> 
> On 2025/8/29 00:44, Askar Safin wrote:
>>   ---- 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).
> 
> Which part of the running system check the cpio signature.

Anyway, built-in cpio may resolve the issue (honestly, I've never tried
this feature), but I'm not sure all users would like to use this way to
bind the customized `init` to the kernel.

Again, I don't have any strong opinion to kill initrd entirely because
I think initdax may be more efficient and I don't have any time to work
on this part -- it's unrelated to my job.

Personally I just don't understand why cpio stands out considering it
even the format itself doesn't support xattrs and more.

Thanks,
Gao Xiang

> 
> Why users need some cpio format (which even cannot be random accessed)
> since it already contains a real filesystem, also which part check the
> signature of `init` itself before `init` runs?  IOWs, why `init` in
> cpio can be trusted to run?
> 
> Why users need to extract the whole cpio to tmpfs just for some data
> part in the erofs? even some data is never used?
> 
> Why the initrd memory cannot be used directly as the dax filesystem
> instead of copying to tmpfs instead?
> 
> Thanks,
> Gao Xiang