All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] init: Print out unknown kernel parameters
@ 2021-05-11 21:10 Andrew Halaney
  2021-05-12 23:00 ` Randy Dunlap
  2021-05-17  8:23 ` Borislav Petkov
  0 siblings, 2 replies; 5+ messages in thread
From: Andrew Halaney @ 2021-05-11 21:10 UTC (permalink / raw)
  To: akpm; +Cc: linux-kernel, Andrew Halaney, Steven Rostedt, Borislav Petkov

It is easy to foobar setting a kernel parameter on the command line
without realizing it, there's not much output that you can use to
assess what the kernel did with that parameter by default.

Make it a little more explicit which parameters on the command line
_looked_ like a valid parameter for the kernel, but did not match
anything and ultimately got tossed to init. This is very similar to the
unknown parameter message received when loading a module.

This assumes the parameters are processed in a normal fashion, some
parameters (dyndbg= for example) don't register their
parameter with the rest of the kernel's parameters, and therefore
always show up in this list (and are also given to init - like the
rest of this list).

Another example is BOOT_IMAGE= is highlighted as an offender, which it
technically is, but is passed by LILO and GRUB so most systems will see
that complaint.

An example output where "foobared" and "unrecognized" are intentionally
invalid parameters:

  Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.12-dirty debug log_buf_len=4M foobared unrecognized=foo
  Unknown command line parameters: foobared BOOT_IMAGE=/boot/vmlinuz-5.12-dirty unrecognized=foo

Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Suggested-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
---

It's my first time sending a v2 via email, please let me know if I've
messed that up in anyway. I decided it wasn't worth the effort to do
"autocorrect" functionality Borislav was pondering about, feel free to
disagree on that if you have a strong opinion.

v2: make output on a single line, make function static and __init,
    include example output in commit message

 init/main.c | 42 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/init/main.c b/init/main.c
index dd11bfd10ead..ac7b364ae8eb 100644
--- a/init/main.c
+++ b/init/main.c
@@ -872,6 +872,47 @@ void __init __weak arch_call_rest_init(void)
 	rest_init();
 }
 
+static void __init print_unknown_bootoptions(void)
+{
+	char *unknown_options;
+	char *end;
+	const char *const *p;
+	size_t len;
+
+	if (panic_later || (!argv_init[1] && !envp_init[2]))
+		return;
+
+	/*
+	 * Determine how many options we have to print out, plus a space
+	 * before each
+	 */
+	len = 1; /* null terminator */
+	for (p = &argv_init[1]; *p; p++) {
+		len++;
+		len += strlen(*p);
+	}
+	for (p = &envp_init[2]; *p; p++) {
+		len++;
+		len += strlen(*p);
+	}
+
+	unknown_options = memblock_alloc(len, SMP_CACHE_BYTES);
+	if (!unknown_options) {
+		pr_err("%s: Failed to allocate %zu bytes\n",
+			__func__, len);
+		return;
+	}
+	end = unknown_options;
+
+	for (p = &argv_init[1]; *p; p++)
+		end += sprintf(end, " %s", *p);
+	for (p = &envp_init[2]; *p; p++)
+		end += sprintf(end, " %s", *p);
+
+	pr_notice("Unknown command line parameters:%s\n", unknown_options);
+	memblock_free(__pa(unknown_options), len);
+}
+
 asmlinkage __visible void __init __no_sanitize_address start_kernel(void)
 {
 	char *command_line;
@@ -913,6 +954,7 @@ asmlinkage __visible void __init __no_sanitize_address start_kernel(void)
 				  static_command_line, __start___param,
 				  __stop___param - __start___param,
 				  -1, -1, NULL, &unknown_bootoption);
+	print_unknown_bootoptions();
 	if (!IS_ERR_OR_NULL(after_dashes))
 		parse_args("Setting init args", after_dashes, NULL, 0, -1, -1,
 			   NULL, set_init_arg);
-- 
2.31.1


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH v2] init: Print out unknown kernel parameters
  2021-05-11 21:10 [PATCH v2] init: Print out unknown kernel parameters Andrew Halaney
@ 2021-05-12 23:00 ` Randy Dunlap
  2021-05-13 13:00   ` Andrew Halaney
  2021-05-17  8:23 ` Borislav Petkov
  1 sibling, 1 reply; 5+ messages in thread
From: Randy Dunlap @ 2021-05-12 23:00 UTC (permalink / raw)
  To: Andrew Halaney, akpm; +Cc: linux-kernel, Steven Rostedt, Borislav Petkov

On 5/11/21 2:10 PM, Andrew Halaney wrote:
> It is easy to foobar setting a kernel parameter on the command line
> without realizing it, there's not much output that you can use to
> assess what the kernel did with that parameter by default.
> 
> Make it a little more explicit which parameters on the command line
> _looked_ like a valid parameter for the kernel, but did not match
> anything and ultimately got tossed to init. This is very similar to the
> unknown parameter message received when loading a module.
> 
> This assumes the parameters are processed in a normal fashion, some
> parameters (dyndbg= for example) don't register their
> parameter with the rest of the kernel's parameters, and therefore
> always show up in this list (and are also given to init - like the
> rest of this list).
> 
> Another example is BOOT_IMAGE= is highlighted as an offender, which it
> technically is, but is passed by LILO and GRUB so most systems will see
> that complaint.
> 
> An example output where "foobared" and "unrecognized" are intentionally
> invalid parameters:
> 
>   Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.12-dirty debug log_buf_len=4M foobared unrecognized=foo
>   Unknown command line parameters: foobared BOOT_IMAGE=/boot/vmlinuz-5.12-dirty unrecognized=foo

Hi Andrew,
What order is the list of unknown command line parameters listed in?


> Suggested-by: Steven Rostedt <rostedt@goodmis.org>
> Suggested-by: Borislav Petkov <bp@suse.de>
> Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
> ---
> 
> It's my first time sending a v2 via email, please let me know if I've
> messed that up in anyway. I decided it wasn't worth the effort to do
> "autocorrect" functionality Borislav was pondering about, feel free to
> disagree on that if you have a strong opinion.
> 
> v2: make output on a single line, make function static and __init,
>     include example output in commit message
> 
>  init/main.c | 42 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 42 insertions(+)


Thanks.
-- 
~Randy


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v2] init: Print out unknown kernel parameters
  2021-05-12 23:00 ` Randy Dunlap
@ 2021-05-13 13:00   ` Andrew Halaney
  2021-05-13 16:06     ` Randy Dunlap
  0 siblings, 1 reply; 5+ messages in thread
From: Andrew Halaney @ 2021-05-13 13:00 UTC (permalink / raw)
  To: Randy Dunlap; +Cc: akpm, linux-kernel, Steven Rostedt, Borislav Petkov

On Wed, May 12, 2021 at 04:00:21PM -0700, Randy Dunlap wrote:
> On 5/11/21 2:10 PM, Andrew Halaney wrote:
> > It is easy to foobar setting a kernel parameter on the command line
> > without realizing it, there's not much output that you can use to
> > assess what the kernel did with that parameter by default.
> > 
> > Make it a little more explicit which parameters on the command line
> > _looked_ like a valid parameter for the kernel, but did not match
> > anything and ultimately got tossed to init. This is very similar to the
> > unknown parameter message received when loading a module.
> > 
> > This assumes the parameters are processed in a normal fashion, some
> > parameters (dyndbg= for example) don't register their
> > parameter with the rest of the kernel's parameters, and therefore
> > always show up in this list (and are also given to init - like the
> > rest of this list).
> > 
> > Another example is BOOT_IMAGE= is highlighted as an offender, which it
> > technically is, but is passed by LILO and GRUB so most systems will see
> > that complaint.
> > 
> > An example output where "foobared" and "unrecognized" are intentionally
> > invalid parameters:
> > 
> >   Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.12-dirty debug log_buf_len=4M foobared unrecognized=foo
> >   Unknown command line parameters: foobared BOOT_IMAGE=/boot/vmlinuz-5.12-dirty unrecognized=foo
> 
> Hi Andrew,
> What order is the list of unknown command line parameters listed in?

Hi Randy,

That's a good question considering that they are out of order in my
example output compared to the command line. The order is parameters
without an "=val", then those with an "=val", and within those groups
they should be ordered as they are on the command line.

This is because I'm using the processing work done by
unknown_bootoption(), which stores them in two separate lists to pass to
init later (for arguments and environment). I am "stealing" from those
here:

	for (p = &argv_init[1]; *p; p++)
		end += sprintf(end, " %s", *p);
	for (p = &envp_init[2]; *p; p++)
		end += sprintf(end, " %s", *p);

hence the differing output order from the command line. I didn't
see much value in trying to duplicate that processing logic to get them in
a single list in the order of the command line itself. I debated looking
at the command line and searching each of the offending lists for that
entry to get them in the order of the command line but decided to keep
it simple here since it was achieving what I wanted.

Thanks,
Andrew


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v2] init: Print out unknown kernel parameters
  2021-05-13 13:00   ` Andrew Halaney
@ 2021-05-13 16:06     ` Randy Dunlap
  0 siblings, 0 replies; 5+ messages in thread
From: Randy Dunlap @ 2021-05-13 16:06 UTC (permalink / raw)
  To: Andrew Halaney; +Cc: akpm, linux-kernel, Steven Rostedt, Borislav Petkov

On 5/13/21 6:00 AM, Andrew Halaney wrote:
> On Wed, May 12, 2021 at 04:00:21PM -0700, Randy Dunlap wrote:
>> On 5/11/21 2:10 PM, Andrew Halaney wrote:
>>> It is easy to foobar setting a kernel parameter on the command line
>>> without realizing it, there's not much output that you can use to
>>> assess what the kernel did with that parameter by default.
>>>
>>> Make it a little more explicit which parameters on the command line
>>> _looked_ like a valid parameter for the kernel, but did not match
>>> anything and ultimately got tossed to init. This is very similar to the
>>> unknown parameter message received when loading a module.
>>>
>>> This assumes the parameters are processed in a normal fashion, some
>>> parameters (dyndbg= for example) don't register their
>>> parameter with the rest of the kernel's parameters, and therefore
>>> always show up in this list (and are also given to init - like the
>>> rest of this list).
>>>
>>> Another example is BOOT_IMAGE= is highlighted as an offender, which it
>>> technically is, but is passed by LILO and GRUB so most systems will see
>>> that complaint.
>>>
>>> An example output where "foobared" and "unrecognized" are intentionally
>>> invalid parameters:
>>>
>>>   Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.12-dirty debug log_buf_len=4M foobared unrecognized=foo
>>>   Unknown command line parameters: foobared BOOT_IMAGE=/boot/vmlinuz-5.12-dirty unrecognized=foo
>>
>> Hi Andrew,
>> What order is the list of unknown command line parameters listed in?
> 
> Hi Randy,
> 
> That's a good question considering that they are out of order in my
> example output compared to the command line. The order is parameters
> without an "=val", then those with an "=val", and within those groups
> they should be ordered as they are on the command line.
> 
> This is because I'm using the processing work done by
> unknown_bootoption(), which stores them in two separate lists to pass to
> init later (for arguments and environment). I am "stealing" from those
> here:
> 
> 	for (p = &argv_init[1]; *p; p++)
> 		end += sprintf(end, " %s", *p);
> 	for (p = &envp_init[2]; *p; p++)
> 		end += sprintf(end, " %s", *p);
> 
> hence the differing output order from the command line. I didn't
> see much value in trying to duplicate that processing logic to get them in
> a single list in the order of the command line itself. I debated looking
> at the command line and searching each of the offending lists for that
> entry to get them in the order of the command line but decided to keep
> it simple here since it was achieving what I wanted.

Thanks for explaining. That's what I was looking for.

-- 
~Randy


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v2] init: Print out unknown kernel parameters
  2021-05-11 21:10 [PATCH v2] init: Print out unknown kernel parameters Andrew Halaney
  2021-05-12 23:00 ` Randy Dunlap
@ 2021-05-17  8:23 ` Borislav Petkov
  1 sibling, 0 replies; 5+ messages in thread
From: Borislav Petkov @ 2021-05-17  8:23 UTC (permalink / raw)
  To: Andrew Halaney; +Cc: akpm, linux-kernel, Steven Rostedt

On Tue, May 11, 2021 at 04:10:09PM -0500, Andrew Halaney wrote:
> It is easy to foobar setting a kernel parameter on the command line
> without realizing it, there's not much output that you can use to
> assess what the kernel did with that parameter by default.
> 
> Make it a little more explicit which parameters on the command line
> _looked_ like a valid parameter for the kernel, but did not match
> anything and ultimately got tossed to init. This is very similar to the
> unknown parameter message received when loading a module.
> 
> This assumes the parameters are processed in a normal fashion, some
> parameters (dyndbg= for example) don't register their
> parameter with the rest of the kernel's parameters, and therefore
> always show up in this list (and are also given to init - like the
> rest of this list).
> 
> Another example is BOOT_IMAGE= is highlighted as an offender, which it
> technically is, but is passed by LILO and GRUB so most systems will see
> that complaint.
> 
> An example output where "foobared" and "unrecognized" are intentionally
> invalid parameters:
> 
>   Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.12-dirty debug log_buf_len=4M foobared unrecognized=foo
>   Unknown command line parameters: foobared BOOT_IMAGE=/boot/vmlinuz-5.12-dirty unrecognized=foo
> 
> Suggested-by: Steven Rostedt <rostedt@goodmis.org>
> Suggested-by: Borislav Petkov <bp@suse.de>
> Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
> ---
> 
> It's my first time sending a v2 via email, please let me know if I've
> messed that up in anyway. I decided it wasn't worth the effort to do
> "autocorrect" functionality Borislav was pondering about, feel free to
> disagree on that if you have a strong opinion.

Oh well, I guess let's first see how this works in practice.

Looks ok to me:

Acked-by: Borislav Petkov <bp@suse.de>

Thx.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-05-17  8:23 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-11 21:10 [PATCH v2] init: Print out unknown kernel parameters Andrew Halaney
2021-05-12 23:00 ` Randy Dunlap
2021-05-13 13:00   ` Andrew Halaney
2021-05-13 16:06     ` Randy Dunlap
2021-05-17  8:23 ` Borislav Petkov

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.