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:
 <8285605c22bd4e818ea6f22ac5551d92211345f2.camel@cyberus-technology.de>
Date: Fri, 21 Mar 2025 12:49:36 +0000
From: Julian Stecklina <julian.stecklina@...erus-technology.de>
To: "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>
CC: "hch@....de" <hch@....de>, "torvalds@...ux-foundation.org"
	<torvalds@...ux-foundation.org>, "gregkh@...uxfoundation.org"
	<gregkh@...uxfoundation.org>, "rafael@...nel.org" <rafael@...nel.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] initrd: support erofs as initrd

Hi Al!

On Fri, 2025-03-21 at 02:08 +0000, Al Viro wrote:
> On Thu, Mar 20, 2025 at 08:28:23PM +0100, Julian Stecklina via B4 Relay wrote:
> > From: Julian Stecklina <julian.stecklina@...erus-technology.de>
> > 
> > Add erofs detection to the initrd mount code. This allows systems to
> > boot from an erofs-based initrd in the same way as they can boot from
> > a squashfs initrd.
> > 
> > Just as squashfs initrds, erofs images as initrds are a good option
> > for systems that are memory-constrained.
> > 
> > Signed-off-by: Julian Stecklina <julian.stecklina@...erus-technology.de>
> 
> >  #include "do_mounts.h"
> >  #include "../fs/squashfs/squashfs_fs.h"
> > +#include "../fs/erofs/erofs_fs.h"
> 
> This is getting really unpleasant...
> 
> Folks, could we do something similar to initcalls - add a section
> (.init.text.rd_detect?) with array of pointers to __init functions
> that would be called by that thing in turn?  With filesystems that
> want to add that kind of stuff being about to do something like

That's a great suggestion! I wonder whether it's possible to restructure the
code further, so it does something along:

1. Try to detect whether it's a (compressed) initramfs -> if so, extract and be
done.
2. Copy the initrd onto /dev/ram and just try to mount it (without the manual fs
detection)

As far as I understand it, the kernel should be able to figure out itself what
filesystem it is? If so, this removes the manual fs detection and just allows
all filesystem images to be used as initrd.

I'm a noob in this part of the code base, so feel free to tell me that/why this
is not possible. :)

Julian