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=VNyt1zG_8pS64wgV8VkZWiWJymnZ-XCfkrfaAhhFSKcA@mail.gmail.com>
Date: Mon, 20 Oct 2025 08:33:07 -0700
From: Doug Anderson <dianders@...omium.org>
To: Randy Dunlap <rdunlap@...radead.org>
Cc: 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>, 
	Geert Uytterhoeven <geert+renesas@...der.be>, 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>
Subject: Re: [PATCH] init/main.c: Wrap long kernel cmdline when printing to logs

Hi,

On Sun, Oct 19, 2025 at 3:23 PM Randy Dunlap <rdunlap@...radead.org> wrote:
>
> Hi,
>
> On 10/19/25 10:06 AM, Douglas Anderson wrote:
> > The kernel cmdline length is allowed to be longer than what printk can
> > handle. When this happens the cmdline that's printed to the kernel
> > ring buffer at bootup is cutoff and some kernel cmdline options are
> > "hidden" from the logs. This undercuts the usefulness of the log
> > message.
> >
> > Add wrapping to the printout. Allow wrapping to be set lower by a
> > Kconfig knob "CONFIG_CMDLINE_LOG_WRAP_IDEAL_LEN". By default, the
> > wrapping is set to 1021 characters, which is measured to be the
> > current maximum that pr_notice() can handle. Anyone whose cmdline
> > isn't being cut off today should see no difference in log output.
> >
> > Wrapping is based on spaces, ignoring quotes. All lines are prefixed
> > with "Kernel command line: " and lines that are not the last line have
> > a " \" suffix added to them. The prefix and suffix count towards the
> > line length for wrapping purposes. The ideal length will be exceeded
> > if no appropriate place to wrap is found.
> >
> > Signed-off-by: Douglas Anderson <dianders@...omium.org>
> > ---
> >
> >  init/Kconfig | 10 +++++++
> >  init/main.c  | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++-
> >  2 files changed, 92 insertions(+), 1 deletion(-)
>
> Is this (length) only a problem for the kernel boot command line?
>
> What does _printk() do with a very long string?

printk() will cut it off at ~1024 characters. The printing of the
kernel command line is backed by pr_notice(), which is backed by
printk(), which is where the limitation is. Yes, we could consider
changing printk() to either remove the 1024 character limitation or
have it do its own word wrapping, but I wouldn't expect people to be
very receptive to that.

Thinking about increasing the maximum printk() size from 1024 to
something bigger, I'd expect the response that people should, in the
general case, not be printing such long strings to the kernel buffer.

Thinking about wrapping directly to printk(), I'd expect:
* People wouldn't like the extra overhead added to every printk() call.
* People wouldn't like the fact that there would be no obvious way to
connect the continuation to the previous line (no way to know what the
common prefix should be).
* It wouldn't be obvious, in the general case, if wrapping should
happen based on spaces.

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.
* We know that wrapping based on spaces is a reasonable thing to do.

If we want this to be something generic, we could certainly put this
function into "lib/", sort of like how print_hex_dump() sits there.
That function is actually a nice parallel to what we're doing here. It
handles adding a prefix and handles intelligent wrapping that makes
sense for the data presented.

My own preference would be to leave the code where it is and, once we
have a second need for similar wrapping we can move the code into
"lib/". That being said, if people think it belongs in "lib/" now I'd
be happy to split this into two patches.

-Doug