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: <568C1099.5000100@sr71.net>
Date:	Tue, 5 Jan 2016 10:51:05 -0800
From:	Dave Hansen <dave@...1.net>
To:	Borislav Petkov <bp@...e.de>
Cc:	x86@...nel.org, linux-kernel@...r.kernel.org,
	dave.hansen@...ux.intel.com, hpa@...or.com, fenghua.yu@...el.com,
	yu-cheng.yu@...el.com
Subject: Re: [PATCH 1/5] x86: fix early command-line parsing when matching at
 end

On 01/05/2016 10:35 AM, Borislav Petkov wrote:
> On Tue, Dec 22, 2015 at 02:52:38PM -0800, Dave Hansen wrote:
>> From: Dave Hansen <dave.hansen@...ux.intel.com>
>> The x86 early command line parsing in cmdline_find_option_bool()
>> is buggy.  If it matches a specified 'option' all the way to
>> the end of the command-line, it will consider it a match.
>>
>> For instance,
>>
>>     	cmdline = "foo";
>>     	cmdline_find_option_bool(cmdline, "fool");
>>
>> will return 1.  This is particularly annoying since we have
>> actual FPU options like "noxsave" and "noxsaves"  So,
>> command-line "foo bar noxsave" will match *BOTH* a "noxsave" and
>> "noxsaves". (This turns out not to be an actual problem because
>> "noxsave" implies "noxsaves", but it's still confusing.)
> 
> So I booted a guest with this command line:
> 
> [    0.000000] Kernel command line: root=/dev/sda1 resume=/dev/sdb1 debug ignore_loglevel log_buf_len=16M earlyprintk=ttyS0,115200 console=ttyS0,115200 console=tty0 noxsave
> 
> after applying the debug hunk below. However, the only debug output I
> got is this:
> 
> [    0.000000] x86_noxsave_setup
> 
> If I supply "noxsaves", I get, as expected
> 
> [    0.000000] x86_noxsaves_setup
> 
> only. Ditto for "noxsaveopt".
> 
> So what am I missing?

The current code uses __setup() which uses different parsing than
cmdline_find_option_bool().  We're going to have to move the noxsave*
ones over to cmdline_find_option_bool() since we need the parsing
earlier than __setup() works.

The changelog should have been more clear on this, though.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ