Re: [RFC PATCH] cmdline: Hide "debug" from /proc/cmdline

From: David Daney
Date: Wed Apr 02 2014 - 18:31:29 EST

On 04/02/2014 03:12 PM, Mateusz Guzik wrote:
On Wed, Apr 02, 2014 at 02:42:19PM -0400, Steven Rostedt wrote:
It has come to our attention that a system running a specific user
space init program will not boot if you add "debug" to the kernel
command line. What happens is that the user space tool parses the
kernel command line, and if it sees "debug" it will spit out so much
information that the system fails to boot. This basically renders the
"debug" option for the kernel useless.

This bug has been reported to the developers of said tool

The response is:

"Generic terms are generic, not the first user owns them."

That is, the "debug" statement on the *kernel* command line is not
owned by the kernel just because it was the first user of it, and
they refuse to fix their bug.

Well, my response is, we OWN the kernel command line, and as such, we
can keep the users from seeing stuff on it if we so choose. And with
that, I propose this patch, which hides "debug" from /proc/cmdline,
such that we don't have to worry about tools parsing for it and causing
hardship for those trying to debug the kernel.

Well, parsing kernel cmdline by systemd is a bad idea, and hiding
"debug" is even worse. What will happen when the next keyword clashes?
And how should I check the kernel is booted with "debug"?

If there is a real need to pass arguments to systemd, how about a
dedicated option (initargs= or whatever, where it has to be last in
cmdline), then systemd would be spawned with these arguments and would
just go over its argv.

What if systemd only parsed kernel command line arguments of the form:

... systemd.arg_foo systemd.arg_bar=x ...

Then it wouldn't get confused by arguments that weren't directly targeted at it.

There is precedence for this form, as it is what we already use for built-in modules. As a bonus, we would be ready for when systemd is integrated into the kernel as a module itself.

David Daney
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at