linux-kernel - Re: [PATCH RESEND 00/62] initrd: remove classic initrd support

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: <CAHNNwZC7gC7zaZGiSBhobSAb4m2O1BuoZ4r=SQBF-tCQyuAPvw@mail.gmail.com>
Date: Mon, 22 Sep 2025 16:28:52 +0200
From: Nicolas Schichan <nschichan@...ebox.fr>
To: Askar Safin <safinaskar@...il.com>
Cc: akpm@...ux-foundation.org, andy.shevchenko@...il.com, axboe@...nel.dk, 
	brauner@...nel.org, cyphar@...har.com, devicetree@...r.kernel.org, 
	ecurtin@...hat.com, email2tema@...il.com, graf@...zon.com, 
	gregkh@...uxfoundation.org, hca@...ux.ibm.com, hch@....de, 
	hsiangkao@...ux.alibaba.com, initramfs@...r.kernel.org, jack@...e.cz, 
	julian.stecklina@...erus-technology.de, kees@...nel.org, 
	linux-acpi@...r.kernel.org, linux-alpha@...r.kernel.org, 
	linux-api@...r.kernel.org, linux-arch@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-block@...r.kernel.org, 
	linux-csky@...r.kernel.org, linux-doc@...r.kernel.org, 
	linux-efi@...r.kernel.org, linux-ext4@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, linux-hexagon@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-m68k@...ts.linux-m68k.org, 
	linux-mips@...r.kernel.org, linux-openrisc@...r.kernel.org, 
	linux-parisc@...r.kernel.org, linux-riscv@...ts.infradead.org, 
	linux-s390@...r.kernel.org, linux-sh@...r.kernel.org, 
	linux-snps-arc@...ts.infradead.org, linux-um@...ts.infradead.org, 
	linuxppc-dev@...ts.ozlabs.org, loongarch@...ts.linux.dev, mcgrof@...nel.org, 
	mingo@...hat.com, monstr@...str.eu, mzxreary@...inter.de, 
	patches@...ts.linux.dev, rob@...dley.net, sparclinux@...r.kernel.org, 
	thomas.weissschuh@...utronix.de, thorsten.blum@...ux.dev, 
	torvalds@...ux-foundation.org, tytso@....edu, viro@...iv.linux.org.uk, 
	x86@...nel.org
Subject: Re: [PATCH RESEND 00/62] initrd: remove classic initrd support

[resending to the lists and Cc, sorry I initially replied only to Askar]

On Sat, Sep 20, 2025 at 5:55 AM Askar Safin <safinaskar@...il.com> wrote:
> On Fri, Sep 19, 2025 at 6:25 PM Nicolas Schichan <nschichan@...ebox.fr> wrote:
> > Considering that the deprecation message didn't get displayed in some
> > configurations, maybe it's a bit early at the very least.
>
> I changed my opinion.
> Breaking users, who did not see a deprecation message at all,
> is unfair.
> I will send a patchset soon, which will remove initrd codepath,
> which currently contains deprecation notice. And I will put
> deprecation notice to
> other codepath.

Thanks

> Then in September 2026 I will fully remove initrd.

Is there a way to find some kind of middle ground here ?

I'm lead to believe that the main issue with the current code is that
it needs to parse the superblocks of the ramdisk image in order to get
the amount to data to copy into /dev/ram0.

It looks like it is partly because of the ramdisk_start= kernel
command line parameter which looks to be a remnant of the time it was
possible to boot on floppy disk on x86.

This kernel command line allows to look for a rootfs image at an
offset into the initrd data.

If we assume now that the rootfs image data starts at the beginning of
the initrd image and is the only part of the initrd image this would
indeed remove a lot of complexity.

Maybe it would be possible to remove the identify_ramdisk_image()
function and just copy the actual size of /initrd.image into
/dev/ram0. This would allow any file system to be used in an initrd
image (no just romfs, cramfs, minixfs, ext2fs and squashfs), and this
would simplify the code in init/do_mounts_rd.c greatly, with just the
function rd_load_image() and nr_blocks() remaining in this file.

I can send a patch for that but first I need to sort out my SMTP
issues from the other day.

Regards,

-- 
Nicolas Schichan