linux-kernel - Re: [PATCH] init/main.c: Wrap long kernel cmdline when printing to logs

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: <CAD=FV=XD19==ed=OPWSvrz-KNQSphHUPwCOqX2-Zi-1o8XE49g@mail.gmail.com>
Date: Tue, 21 Oct 2025 09:07:40 -0700
From: Doug Anderson <dianders@...omium.org>
To: Heiko Carstens <hca@...ux.ibm.com>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>, Randy Dunlap <rdunlap@...radead.org>, 
	linux-kernel@...r.kernel.org, Andrew Chant <achant@...gle.com>, 
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>, 
	Andrew Morton <akpm@...ux-foundation.org>, Brian Gerst <brgerst@...il.com>, 
	Christian Brauner <brauner@...nel.org>, Francesco Valla <francesco@...la.it>, 
	Guo Weikang <guoweikang.kernel@...il.com>, Huacai Chen <chenhuacai@...nel.org>, 
	Jan Hendrik Farr <kernel@...rr.cc>, Jeff Xu <jeffxu@...omium.org>, Kees Cook <kees@...nel.org>, 
	Masahiro Yamada <masahiroy@...nel.org>, Michal Koutný <mkoutny@...e.com>, 
	Miguel Ojeda <ojeda@...nel.org>, "Mike Rapoport (Microsoft)" <rppt@...nel.org>, 
	Nathan Chancellor <nathan@...nel.org>, Peter Zijlstra <peterz@...radead.org>, 
	Shakeel Butt <shakeel.butt@...ux.dev>, Tejun Heo <tj@...nel.org>, 
	Thomas Gleixner <tglx@...utronix.de>, Thomas Weißschuh <thomas.weissschuh@...utronix.de>, 
	"Uladzislau Rezki (Sony)" <urezki@...il.com>, Sven Schnelle <svens@...ux.ibm.com>, 
	linux-s390 <linux-s390@...r.kernel.org>
Subject: Re: [PATCH] init/main.c: Wrap long kernel cmdline when printing to logs

Hi,

On Tue, Oct 21, 2025 at 6:16 AM Heiko Carstens <hca@...ux.ibm.com> wrote:
>
> On Tue, Oct 21, 2025 at 09:05:48AM +0200, Geert Uytterhoeven wrote:
> > On Mon, 20 Oct 2025 at 18:04, Doug Anderson <dianders@...omium.org> wrote:
> > > On Mon, Oct 20, 2025 at 8:42 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > > > On Mon, 20 Oct 2025 at 17:33, Doug Anderson <dianders@...omium.org> wrote:
> > > > > Printing the command line to the kernel log buffer is one of the very
> > > > > rare cases where:
> > > > > * There's a legitimate reason to print a (potentially) very long
> > > > > string to the kernel buffer.
> > > >
> > > > arch/s390/Kconfig:
> > > >
> > > >     config COMMAND_LINE_SIZE
> > > >             int "Maximum size of kernel command line"
> > > >             default 4096
> > > >             range 896 1048576
> > > >
> > > > Yummy...
> > >
> > > Wow, what are they expecting to stuff in there? An encoded initramfs
> > > or something? I kinda feel like the 1MB number isn't something anyone
> > > expects but is a number picked to effectively be "unlimited".
> >
> > Dunno, commit 622021cd6c560ce7 ("s390: make command line configurable")
> > lacks the "why" part.
>
> That was just a follow-on patch of commit 5ecb2da660ab ("s390: support command
> lines longer than 896 bytes") which solved the real problem with a too short
> maximum command line size back then. In order to never have to deal with this
> sort of problem again it was made configurable.
>
> But I doubt that anybody will change the default ever.

OK, so my theory that 1MB cmdline is not normal / realistic / expected
sounds correct. Essentially it's just saying "we didn't want to pick a
limit". We could add a bound to what's printed if we want (4K? 16K?),
but it's maybe not critical since we wouldn't expect crazy long
cmdlines anyway.

So I guess the question is whether any of my arguments convinced
Andrew that my current wrapping logic is OK. If not, hopefully he can
clarify if either of my theories of what he meant by "chunking" were
correct and then I can send a v2. ;-)

Of course, given that the max cmdline for most architectures is
something like 2K/4K, it also might not be too horrible to just
increase the printk limit? I was assuming that would be too
controversial...

-Doug



-Doug