linux-kernel - Re: [PATCH v2] 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d77f6819-9d3b-8d50-16cb-fff1a62dc67d@infradead.org>
Date:   Thu, 13 May 2021 09:06:35 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Andrew Halaney <ahalaney@...hat.com>
Cc:     akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
        Steven Rostedt <rostedt@...dmis.org>,
        Borislav Petkov <bp@...e.de>
Subject: Re: [PATCH v2] init: Print out unknown kernel parameters

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