linux-kernel - Re: [GIT PULL] bootconfig: Updates for 6.6

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

Message-ID: <CAHk-=wjpVAW3iRq_bfKnVfs0ZtASh_aT67bQBG11b4W6niYVUw@mail.gmail.com>
Date:   Sat, 2 Sep 2023 11:35:00 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "Paul E. McKenney" <paulmck@...nel.org>
Subject: Re: [GIT PULL] bootconfig: Updates for 6.6

On Fri, 1 Sept 2023 at 18:10, Masami Hiramatsu <mhiramat@...nel.org> wrote:
>
>  - fs/proc: Add /proc/raw_cmdline for boot loader arguments.

Honestly, I pulled this, and then I unpulled again.

This seems such a *silly* thing. It's also actively confusing, since
this "raw" file internally in the kernel is called
"boot_command_line", vs the "saved_command_line" of the regular one,
and we also have 'extra_command_line' and 'static_command_line' etc,
so where does this all end?

So the name doesn't even make any sense. It's not "raw" in any sense
of the word. It just happens to be the one that came from the boot
side.

In other words, this smells like a complete hack to me. It makes no
sense, and it should *not* be added to the top-level /proc filesystem
as some kind of fundamental file.

And not only is it a special case that isn't worthy of adding to the
top-level /proc directory, it only has _one_ special case user that
could possibly care.

And this is all self-inflicted pain because the bootconfig code
corrupted the original command line, and decided to expose that
corrupted thing in /proc/cmdline.

So because you made a mess of it originally, you're now making a
*bigger* mess of this all.

No, thank you. The way to fix a mess is not to make it worse. And this
just makes things worse.

I suspect the fix should always have been to make the extra stuff be
somehow clear so that you can parse it. Not make another file that has
the exact same contents for most people.

Maybe a marker of "this is the end of the 'extra command line", the
same way we have that "--" for "this is the end of the stuff the
kernel should parse".

           Linus