linux-kernel - Re: [PATCH 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 for Android: free password hash cracker in your pocket

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

Message-ID: <CALCETrXHxOkHoS+0zhvc4cfpZqJ0wpfQUDnXW-A-qyQkqur-DQ@mail.gmail.com>
Date: Wed, 17 Sep 2025 11:00:32 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Rob Landley <rob@...dley.net>
Cc: Askar Safin <safinaskar@...omail.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 00/62] initrd: remove classic initrd support

On Mon, Sep 15, 2025 at 10:09 AM Rob Landley <rob@...dley.net> wrote:

> While you're at it, could you fix static/builtin initramfs so PID 1 has
> a valid stdin/stdout/stderr?
>
> A static initramfs won't create /dev/console if the embedded initramfs
> image doesn't contain it, which a non-root build can't mknod, so the
> kernel plumbing won't see it dev in the directory we point it at unless
> we build with root access.

I have no current insight as to whether there's a kernel issue here,
but why are you trying to put actual device nodes in an actual
filesystem as part of a build process?  It's extremely straightforward
to emit devices nodes in cpio format, and IMO it's far *more*
straightforward to do that than to make a whole directory, try to get
all the modes right, and cpio it up.

I wrote an absolutely trivial tool for this several years ago:

https://github.com/amluto/virtme/blob/master/virtme/cpiowriter.py

it would be barely more complicated to strip the trailer off an cpio
file from some other source, add some device nodes, and stick the
trailer back on.  But it's also really, really, really easy to emit an
entire, functioning cpio-formatted initramfs from plain user code with
no filesystem manipulation at all.  This also makes that portion of
the build reproducible, which is worth quite a bit IMO.

--Andy