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 for Android: free password hash cracker in your pocket

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

Message-ID: <a54ced51-280e-cc9d-38e4-5b592dd9e77b@winds.org>
Date: Tue, 26 Aug 2025 10:21:50 -0400 (EDT)
From: Byron Stanoszek <gandalf@...ds.org>
To: Christoph Hellwig <hch@....de>, Askar Safin <safinaskar@...omail.com>
cc: gregkh@...uxfoundation.org, julian.stecklina@...erus-technology.de, 
    linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, 
    rafael@...nel.org, torvalds@...ux-foundation.org, viro@...iv.linux.org.uk, 
    Gao Xiang <hsiangkao@...ux.alibaba.com>, 
    Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Subject: Re: [PATCH] initrd: support erofs as initrd

On Tue, 26 Aug 2025, Christoph Hellwig wrote:

> On Mon, Aug 25, 2025 at 09:27:13PM +0300, Askar Safin wrote:
>>> We've been trying to kill off initrd in favor of initramfs for about
>>> two decades.  I don't think adding new file system support to it is
>>> helpful.
>>
>> I totally agree.
>>
>> What prevents us from removing initrd right now?
>>
>> The only reason is lack of volunteers?
>>
>> If yes, then may I remove initrd?
>
> Give it a spin and see if anyone shouts.

Well, this makes me a little sad. I run several hundred embedded systems out in
the world, and I use a combination of initrd and initramfs for booting. These
systems operate entirely in ramdisk form.

I concatenate a very large .sqfs file onto the end of "vmlinuz", which gets
loaded into initrd automatically by the bootloader. Then in my initramfs (cpio
archive that's compiled in with the kernel), my /sbin/init executable copies
/initrd.image to /dev/ram0, mounts a tmpfs overlay on top of it, then does a
pivot root to it.

This gives it the appearance of a read-write initramfs filesystem, but the
lower layer data remains compressed in RAM. This saves quite a bit of RAM
during runtime, which is still yet important on older PCs.

If there's a better (more official) way of having a real compressed initramfs
that remains compressed during runtime, I'm all for it. But until then, I would
like to ask you to please not remove the initrd functionality.

(In fact, I was actually thinking about trying this method with erofs as the
lower layer filesystem someday soon instead of squashfs. But I would still be
using an overlay to mount it, instead of the auto-detect method addressed by
this patch.)

Thank you,
  -Byron