Re: [PATCH] initrd: support erofs as initrd

[Gao Xiang <hsiangkao@linux.alibaba.com>]

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@linux.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