Re: [PATCH] init: Print out unknown kernel parameters

[Randy Dunlap]

Hi--

On 5/3/21 2:34 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).

As you say, unknown parameters are just given to init -- they are not
errors.

However, if someone is experiencing a problem, can't they just boot
with the addition of "debug" to the kernel command line and then they
can see what arguments and environment are being passed to the init
process?  E.g.:

[    9.453693] Run /sbin/init as init process
[    9.456886]   with arguments:
[    9.460014]     /sbin/init
[    9.463121]     showopts
[    9.466157]     fb=font:VGA8x8
[    9.469172]   with environment:
[    9.472146]     HOME=/
[    9.475152]     TERM=linux
[    9.478103]     BOOT_IMAGE=/boot/bzImage-next0409
[    9.481057]     resume=/dev/sda7
[    9.484006]     splash=native
[    9.495272]     v1de0=vesafb


Can you show an example of what this code prints?

thanks.

> 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.
> 
> Suggested-by: Steven Rostedt <rostedt@xxxxxxxxxxx>
> Suggested-by: Borislav Petkov <bp@xxxxxxx>
> Signed-off-by: Andrew Halaney <ahalaney@xxxxxxxxxx>
> ---
> 
> Hello,
> 
> This idea was suggested by rostedt and bpetkov, not sure what they'll
> think of the implementation :P Please let me know if you've got
> suggestions (or hate the idea in general).
> 
> Piggybacking on unknown_bootoption()'s assessment of the
> parameters made this pretty straight forward, but I'm a bit unhappy with
> dyndbg and BOOT_IMAGE showing up. I didn't want to make an exception for
> them, so I left it as is and decided that their oddities ought to be
> shown in the output still. The format of the output is borrowed from the
> dynamic debug statements for printing init's env/argv lines.
> 
> Due to the BOOT_IMAGE bit I didn't actually ever get to exercise the
> early return (limited on my test systems right now) but I think I got
> that statement correct.
> 
> Thanks,
> Andrew
> 
>  init/main.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/init/main.c b/init/main.c
> index dd11bfd10ead..cd313f1bc7b0 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -872,6 +872,20 @@ void __init __weak arch_call_rest_init(void)
>  	rest_init();
>  }
>  
> +void print_unknown_bootoptions(void)
> +{
> +	const char *const *p;
> +
> +	if (panic_later || (!argv_init[1] && !envp_init[2]))
> +		return;
> +
> +	pr_notice("Unknown command line parameters:\n");
> +	for (p = &argv_init[1]; *p; p++)
> +		pr_notice("    %s\n", *p);
> +	for (p = &envp_init[2]; *p; p++)
> +		pr_notice("    %s\n", *p);
> +}
> +
>  asmlinkage __visible void __init __no_sanitize_address start_kernel(void)
>  {
>  	char *command_line;
> @@ -913,6 +927,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);
> 


-- 
~Randy