public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@suse.de>
To: Dave Hansen <dave@sr71.net>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	dave.hansen@linux.intel.com, hpa@zytor.com, fenghua.yu@intel.com,
	yu-cheng.yu@intel.com
Subject: Re: [PATCH 1/5] x86: fix early command-line parsing when matching at end
Date: Wed, 6 Jan 2016 18:10:32 +0100	[thread overview]
Message-ID: <20160106171032.GA20321@pd.tnic> (raw)
In-Reply-To: <20151222225238.9AEB560C@viggo.jf.intel.com>

On Tue, Dec 22, 2015 at 02:52:38PM -0800, Dave Hansen wrote:
> 
> From: Dave Hansen <dave.hansen@linux.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.)
> 
> To fix this, we simplify the code and stop tracking 'len'.  'len'
> was trying to indicate either the NULL terminator *OR* the end of
> a non-NULL-terminated commandline at 'COMMAND_LINE_SIZE'.  But,
> each of the three states is *already* checking 'cmdline' for a
> NULL terminator.
> 
> We _only_ need to check if we have overrun 'COMMAND_LINE_SIZE',
> and that we can do without keeping 'len' around.
> 
> Also add some commends to clarify what is going on.
> 
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: linux-kernel@vger.kernel.org
> Cc: fenghua.yu@intel.com
> Cc: yu-cheng.yu@intel.com
> ---
> 
>  b/arch/x86/lib/cmdline.c |   34 ++++++++++++++++++++++++----------
>  1 file changed, 24 insertions(+), 10 deletions(-)
> 
> diff -puN arch/x86/lib/cmdline.c~x86-broken-end-of-string-command-line-parsing arch/x86/lib/cmdline.c
> --- a/arch/x86/lib/cmdline.c~x86-broken-end-of-string-command-line-parsing	2015-12-22 11:56:58.639149442 -0800
> +++ b/arch/x86/lib/cmdline.c	2015-12-22 11:56:58.642149577 -0800
> @@ -21,12 +21,14 @@ static inline int myisspace(u8 c)
>   * @option: option string to look for
>   *
>   * Returns the position of that @option (starts counting with 1)
> - * or 0 on not found.
> + * or 0 on not found.  @option will only be found if it is found
> + * as an entire word in @cmdline.  For instance, if @option="car"
> + * then a cmdline which contains "cart" will not match.
>   */
>  int cmdline_find_option_bool(const char *cmdline, const char *option)
>  {
>  	char c;
> -	int len, pos = 0, wstart = 0;
> +	int pos = 0, wstart = 0;
>  	const char *opptr = NULL;
>  	enum {
>  		st_wordstart = 0,	/* Start of word/after whitespace */
> @@ -37,11 +39,14 @@ int cmdline_find_option_bool(const char
>  	if (!cmdline)
>  		return -1;      /* No command line */
>  
> -	len = min_t(int, strlen(cmdline), COMMAND_LINE_SIZE);
> -	if (!len)
> +	if (!strlen(cmdline))
>  		return 0;
>  
> -	while (len--) {
> +	/*
> +	 * This 'pos' check ensures we do not overrun
> +	 * a non-NULL-terminated 'cmdline'
> +	 */
> +	while (pos < COMMAND_LINE_SIZE) {

So this is a little bit strange: you're checking strlen(cmdline) above
but iterating until COMMAND_LINE_SIZE.

I think we should make it even more palatable:

	while (pos < min_t(int, strlen(cmdline), COMMAND_LINE_SIZE))

so that it is obvious how far we iterate. I know, I know, it boils down
to the same code because each state is checking !c but this way it is
clearer what we're doing when someone looks at that code again.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

  parent reply	other threads:[~2016-01-06 17:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-22 22:52 [PATCH 0/5] x86: early command-line parsing fixes / tests (v2) Dave Hansen
2015-12-22 22:52 ` [PATCH 1/5] x86: fix early command-line parsing when matching at end Dave Hansen
2016-01-05 18:35   ` Borislav Petkov
2016-01-05 18:51     ` Dave Hansen
2016-01-06 17:10   ` Borislav Petkov [this message]
2016-01-06 17:57   ` Dave Hansen
2016-01-06 18:14     ` Borislav Petkov
2016-02-03 11:34   ` [tip:x86/boot] x86/boot: Fix " tip-bot for Dave Hansen
2015-12-22 22:52 ` [PATCH 2/5] x86: fix early command-line parsing, when partial word match Dave Hansen
2016-02-03 11:35   ` [tip:x86/boot] x86/boot: Fix early command-line parsing when partial word matches tip-bot for Dave Hansen
2015-12-22 22:52 ` [PATCH 3/5] x86: simplify early command line parsing Dave Hansen
2016-01-06 17:10   ` Borislav Petkov
2016-01-06 17:35     ` Dave Hansen
2016-01-06 17:37     ` Dave Hansen
2016-01-06 17:48       ` Borislav Petkov
2016-02-03 11:35   ` [tip:x86/boot] x86/boot: Simplify " tip-bot for Dave Hansen
2015-12-22 22:52 ` [PATCH 4/5] x86: pass in size to early cmdline parsing Dave Hansen
2016-02-03 11:36   ` [tip:x86/boot] x86/boot: Pass " tip-bot for Dave Hansen
2015-12-22 22:52 ` [PATCH 5/5] x86: test early command-line code Dave Hansen
2016-01-27 12:28   ` Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160106171032.GA20321@pd.tnic \
    --to=bp@suse.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=dave@sr71.net \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@kernel.org \
    --cc=yu-cheng.yu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox