linux-kernel - [PATCH] init: Print out unknown kernel parameters

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]

Date:   Mon,  3 May 2021 16:34:01 -0500
From:   Andrew Halaney <ahalaney@...hat.com>
To:     akpm@...ux-foundation.org
Cc:     linux-kernel@...r.kernel.org, Andrew Halaney <ahalaney@...hat.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Borislav Petkov <bp@...e.de>
Subject: [PATCH] init: Print out unknown kernel parameters

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.

Suggested-by: Steven Rostedt <rostedt@...dmis.org>
Suggested-by: Borislav Petkov <bp@...e.de>
Signed-off-by: Andrew Halaney <ahalaney@...hat.com>
---

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);
-- 
2.30.2