Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 5 May 2021 11:37:28 -0500
From:   Andrew Halaney <ahalaney@redhat.com>
To:     Borislav Petkov <bp@suse.de>
Cc:     Steven Rostedt <rostedt@goodmis.org>,
        Randy Dunlap <rdunlap@infradead.org>,
        akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] init: Print out unknown kernel parameters
Message-ID: <20210505163728.oh7rqpdvxrdilmfk@halaneylaptop>
References: <20210503213400.27360-1-ahalaney@redhat.com>
 <dfc44b3f-a810-cfbe-f13f-39548ab3fb08@infradead.org>
 <20210503184606.5e8461c0@gandalf.local.home>
 <YJFho3AasxxcD/hH@zn.tnic>
 <20210504152614.mgiihv4ukqajo3jb@halaneylaptop>
 <YJKpv6vjCcCkbzNT@zn.tnic>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YJKpv6vjCcCkbzNT@zn.tnic>
Precedence: bulk

On Wed, May 05, 2021 at 04:20:47PM +0200, Borislav Petkov wrote:
> On Tue, May 04, 2021 at 10:26:14AM -0500, Andrew Halaney wrote:
> > Definitely a matter of opinion, but with the kernel having specific
> > ways to denote init destined parameters (anything after "--") I think
> > an unconditional message is acceptable.
> 
> Or - and I had alluded to that on IRC - you *actually* know which params
> are kernel params:
> 
> #define __setup_param(str, unique_id, fn, early)                        \
>         static const char __setup_str_##unique_id[] __initconst         \
>                 __aligned(1) = str;                                     \
>         static struct obs_kernel_param __setup_##unique_id              \
>                 __used __section(".init.setup")                         \
> 				^^^^^^^^^^^^^^^^^^
> 
>                 __aligned(__alignof__(struct obs_kernel_param))         \
>                 = { __setup_str_##unique_id, fn, early }
> 
> 
> all those guys in the above section.
I actually did use that recommendation essentially, the patch I've sent
is riding on the work done by unknown_bootoption() which is populated by
iterating over over the different sections parameters can live in - so
this is only printing out arguments that didn't match a known kernel
parameter. Sorry if I didn't make that clear earlier, definitely was
trying to listen to your advice.

> 
> So you'd have iterate over those and do some cheap version of those
> autocorrect algorithms which guess which words you meant. For example,
> if you have:
> 
> panik_on_oops instead of
> panic_on_oops
> 
> the difference is one letter so it is likely a mistyped param rather
> than something which goes to init or other random garbage and then you
> warn.
> 
> Something like that.
> 
> It would need a lot of experimentation first, though, to see whether
> this makes sense and it is workable at all.
I'll have to think about this some more (the "did you mean this
parameter" part).. that seems like it might be more trouble than it is
worth, but I admittedly haven't looked into those cheap algorithms you
mentioned yet. The reason I say it might be more trouble than it is
worth is because it is easy to say "why didn't my param work", then grep
for it in dmesg and find it in the "Unknown command line parameters"
list - that's sort of the workflow I imagined would happen when someone
mucks with their kernel cli and doesn't get the intended result.

Thanks,
Andrew