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 <[email protected]>
Suggested-by: Borislav Petkov <[email protected]>
Signed-off-by: Andrew Halaney <[email protected]>
---
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
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 <[email protected]>
> Suggested-by: Borislav Petkov <[email protected]>
> Signed-off-by: Andrew Halaney <[email protected]>
> ---
>
> 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
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
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
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 <[email protected]>
> Suggested-by: Borislav Petkov <[email protected]>
> Signed-off-by: Andrew Halaney <[email protected]>
> ---
>
> 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 <[email protected]>
Thx.
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg