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:
 <a1c9c97458a86e35df3f6626c9b7c8be4448a9f0.camel@cyberus-technology.de>
Date: Mon, 7 Apr 2025 11:19:27 +0000
From: Julian Stecklina <julian.stecklina@...erus-technology.de>
To: "hch@....de" <hch@....de>
CC: "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"rafael@...nel.org" <rafael@...nel.org>, "viro@...iv.linux.org.uk"
	<viro@...iv.linux.org.uk>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "hsiangkao@...ux.alibaba.com"
	<hsiangkao@...ux.alibaba.com>
Subject: Re: [PATCH] initrd: support erofs as initrd

Hi!

On Mon, 2025-04-07 at 10:57 +0200, hch@....de wrote:
> On Fri, Mar 21, 2025 at 01:17:54PM +0000, Julian Stecklina wrote:
> > Of course there are some solutions to using erofs images at boot now:
> > https://github.com/containers/initoverlayfs
> > 
> > But this adds yet another step in the already complex boot process and feels
> > like a hack. It would be nice to just use erofs images as initrd. The other
> > building block to this is automatically sizing /dev/ram0:
> > 
> > https://lkml.org/lkml/2025/3/20/1296
> > 
> > I didn't pack both patches into one series, because I thought enabling erofs
> > itself would be less controversial and is already useful on its own. The
> > autosizing of /dev/ram is probably more involved than my RFC patch. I'm
> > hoping
> > for some input on how to do it right. :)
> 
> Booting from erofs seems perfectly fine to me.  Booting from erofs on
> an initrd is not.  There is no reason to fake up a block device, just
> have a version of erofs that directly points to pre-loaded kernel
> memory instead.  This is a bit more work, but a lot more efficient
> in that it removes the block path from the I/O stack, removes the boot
> time copy and allows for much more flexible memory management.

Can you be more specific in how that would look like in practice? The
infrastructure for initrds is universally available and what you are proposing
sounds like adding a new mechanism entirely?

Julian

PS. Sorry for the re-send. I accidentally sent a HTML mail. :(