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] [thread-next>] [day] [month] [year] [list]

Message-ID: <de56cabd-05a9-4528-8150-9ad97209640e@landley.net>
Date: Wed, 24 Sep 2025 14:20:47 -0500
From: Rob Landley <rob@...dley.net>
To: Alexander Patrakov <patrakov@...il.com>,
 Christophe Leroy <christophe.leroy@...roup.eu>
Cc: Askar Safin <safinaskar@...il.com>, linux-fsdevel@...r.kernel.org,
 linux-kernel@...r.kernel.org, Linus Torvalds
 <torvalds@...ux-foundation.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Christian Brauner <brauner@...nel.org>, Al Viro <viro@...iv.linux.org.uk>,
 Jan Kara <jack@...e.cz>, Christoph Hellwig <hch@....de>,
 Jens Axboe <axboe@...nel.dk>, Andy Shevchenko <andy.shevchenko@...il.com>,
 Aleksa Sarai <cyphar@...har.com>,
 Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
 Julian Stecklina <julian.stecklina@...erus-technology.de>,
 Gao Xiang <hsiangkao@...ux.alibaba.com>, Art Nikpal <email2tema@...il.com>,
 Andrew Morton <akpm@...ux-foundation.org>, Eric Curtin <ecurtin@...hat.com>,
 Alexander Graf <graf@...zon.com>, Lennart Poettering <mzxreary@...inter.de>,
 linux-arch@...r.kernel.org, linux-alpha@...r.kernel.org,
 linux-snps-arc@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org,
 linux-csky@...r.kernel.org, linux-hexagon@...r.kernel.org,
 loongarch@...ts.linux.dev, linux-m68k@...ts.linux-m68k.org,
 linux-mips@...r.kernel.org, linux-openrisc@...r.kernel.org,
 linux-parisc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
 linux-riscv@...ts.infradead.org, linux-s390@...r.kernel.org,
 linux-sh@...r.kernel.org, sparclinux@...r.kernel.org,
 linux-um@...ts.infradead.org, x86@...nel.org, Ingo Molnar
 <mingo@...hat.com>, linux-block@...r.kernel.org, initramfs@...r.kernel.org,
 linux-api@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-efi@...r.kernel.org, linux-ext4@...r.kernel.org,
 "Theodore Y . Ts'o" <tytso@....edu>, linux-acpi@...r.kernel.org,
 Michal Simek <monstr@...str.eu>, devicetree@...r.kernel.org,
 Luis Chamberlain <mcgrof@...nel.org>, Kees Cook <kees@...nel.org>,
 Thorsten Blum <thorsten.blum@...ux.dev>, Heiko Carstens <hca@...ux.ibm.com>,
 patches@...ts.linux.dev
Subject: Re: [PATCH RESEND 00/62] initrd: remove classic initrd support

On 9/24/25 11:17, Alexander Patrakov wrote:
>> Therefore is it really initrd you are removing or just some corner case
>> ? If it is really initrd, then how does QEMU still work with that
>> -initrd parameter ?
> 
> The QEMU -initrd parameter is a misnomer. It can be used to pass an
> initrd or an initramfs, and the kernel automatically figures out what
> it is.

It's not a misnomer, initrams has always been able to make use of the 
existing initrd loading mechanism to read images externally supplied by 
the bootloader. It's what grub calls it too. I documented it in the 
"External initramfs images" section of 
https://kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt 
back in 2005. The mechanism itself is 30 years old 
(Documentation/initrd.txt was written by Werner Almsberger in linux 
1.3.73 from March 7, 1996, ala 
https://github.com/mpe/linux-fullhistory/commit/afc106342783 ).

Since initrd contents could always be in a bunch of different 
autodetected formats (and optionally compressed just like the kernel), 
initramfs just hooked in to the staircase and said "if the format is 
cpio, call this function to handle it". The patch series proposes 
removing all the other formats, but not otherwise changing the existing 
external image loader mechanism. (Personally I think removing the 
architecture-specific hacks but leaving the generic support under init/ 
would probably have made more sense as a first step.)

The bootloader hands off an initrd image, initramfs is the boot-time 
cpio extraction plumbing that's _init tagged and gets freed, and rootfs 
is the persistent mounted instance of ramfs or tmpfs that's always there 
and is analogous to the init task (PID 1) except for the mount tree. 
(And is often overmounted so it's not visible, but it's still there. And 
is NOT SPECIAL: overmounts aren't a new concept, nor is hiding them in 
things like "df".)

There's a REASON my documentation file was called 
ramfs-rootfs-initramfs.txt: the naming's always been a bit... layered. 
(And yes, I have always spelled initmpfs with only one t.)

Rob