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: <055bbf1a-8eb7-7f77-5ea8-31d2ecaf1d4b@roeck-us.net>
Date:   Tue, 6 Oct 2020 04:17:03 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Petr Mladek <pmladek@...e.com>,
        Shreyas Joshi <shreyas.joshi@...mp.com>, rostedt@...dmis.org,
        shreyasjoshi15@...il.com, linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] printk: handle blank console arguments passed in.

On 10/5/20 10:08 PM, Greg Kroah-Hartman wrote:
> On Mon, Oct 05, 2020 at 08:35:59PM -0700, Guenter Roeck wrote:
>> On 10/5/20 7:59 PM, Sergey Senozhatsky wrote:
>>> Cc-ing Guenter,
>>>
>>> On (20/05/22 12:00), Petr Mladek wrote:
>>>> On Fri 2020-05-22 16:53:06, Shreyas Joshi wrote:
>>>>> If uboot passes a blank string to console_setup then it results in a trashed memory.
>>>>> Ultimately, the kernel crashes during freeing up the memory. This fix checks if there
>>>>> is a blank parameter being passed to console_setup from uboot.
>>>>> In case it detects that the console parameter is blank then
>>>>> it doesn't setup the serial device and it gracefully exits.
>>>>>
>>>>> Signed-off-by: Shreyas Joshi <shreyas.joshi@...mp.com>
>>>>> ---
>>>>>  V1:
>>>>>     Fixed console_loglevel to default as per the review comments
>>>>>
>>>>>  kernel/printk/printk.c | 5 ++++-
>>>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
>>>>> index ad4606234545..e9ad730991e0 100644
>>>>> --- a/kernel/printk/printk.c
>>>>> +++ b/kernel/printk/printk.c
>>>>> @@ -2165,7 +2165,10 @@ static int __init console_setup(char *str)
>>>>>  	char buf[sizeof(console_cmdline[0].name) + 4]; /* 4 for "ttyS" */
>>>>>  	char *s, *options, *brl_options = NULL;
>>>>>  	int idx;
>>>>> -
>>>>> +	if (str[0] == 0) {
>>>>> +		return 1;
>>>>> +	}
>>>>>  	if (_braille_console_setup(&str, &brl_options))
>>>>>  		return 1;
>>>>
>>>> I have fixed formatting and pushed it into printk/linux.git,
>>>> branch for-5.8.
>>>
>>> Petr, this patch's causing regressions for us. We use blank console= boot
>>> param to bypass dts. It appears that it'd be better to revert the change.
>>>
>>
>> Not just to bypass dts, it was also possible to use console= to disable consoles
>> passed as config option, as well as other default console options. A quick test
>> confirms that this affects all platforms/architectures, not just Chromebooks.
>> Prior to this patch, it was possible to disable a default console with an
>> empty "console=" parameter. This is no longer possible. This means that
>> this patch results in a substantial (and, as far as I can see, completely
>> undiscussed) functionality change.
>>
>> I don't understand why (yet), but the patch also causes regressions with
>> seemingly unrelated functionality, specifically with dm-verity on at least
>> one Chromebook platform. I filed crbug.com/1135157 to track the problem,
>> and reverted the patch from all our stable releases immediately after
>> the last round of stable release merges.
>>
>> On a side note, I don't see the problem presumably fixed with this
>> patch in any of my tests.
> 
> I have no problem reverting this in the stable trees, but are you going
> to hit this issue in Linus's tree in the next release?
> 

Not sure what you mean with "next release". As mentioned, I already reverted
the patch from all Chrome OS stable branches. We have already seen the problem
in the top-of-tree test branch (which is presumably why Sergey brought it up
back in May), so we'll definitely have to either revert this patch in the next
Chrome OS stable branch (presumably based on 5.10 unless that changes), or
we'll have to find find some other (backward-compatible) solution to disable
the default console on Chromebooks.

Since the patch is already reverted in our branches, it is not an urgent
problem for us. But we will need some solution - I really don't want to
carry reverts of upstream patches in our trees.

Guenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ