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: <5199BD45.5090100@gmail.com>
Date:	Sun, 19 May 2013 23:05:57 -0700
From:	Brian Norris <computersforpeace@...il.com>
To:	Huang Shijie <b32955@...escale.com>, vikram186@...il.com
CC:	dwmw2@...radead.org, dedekind1@...il.com,
	linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 05/10 fix] mtd: get the ECC info from the Extended
 Parameter Page

Hi Huang, Vikram,

On 05/19/2013 07:08 PM, Huang Shijie wrote:
...
> +	/*
> +	 * From section 5.7.2.2, we know that the Extened Param Page is valid
> +	 * when two or more bytes of the signatrue are valid.

s/signatrue/signature

> +	 * So we only check the first two bytes here.
> +	 */
> +	if (strncmp(ep->sig, "EP", 2)) {
> +		pr_debug("The signatrue is invalid.\n");

Ditto.

> +		goto ext_out;
> +	}

What's the reasoning about this whole "only check 2 bytes" thing? I 
understand that this is technically what spec *says* (although you're 
actually not checking the other 5 combinations that are valid: 'ExPx' 
'ExxS' 'xPPx' 'xPxS' 'xxPS'). But *why* does the spec say this? To 
tolerate errors or to tolerate changes in the spec (e.g., new types of 
parameter pages that say 'QPPS' [1], for instance)? The former doesn't 
really sound plausible, since if we're going to have 2 whole bytes of 
errors in the signature, then we really shouldn't trust the whole 
(extended) parameter page. And the latter doesn't really make sense to 
me; any future backwards-compatible modifications should just use the 
same signature string.

Anyway, my point is that there has to be some logic to strictly 
following the letter of the specification. Shortening the check to just 
the 2-byte "EP" string does not actually cover *exactly* what the spec 
might allow (e.g., it doesn't allow "QPPS" [1]). But it also doesn't 
make any sense why we want to check anything besides "EPPS". So my 
natural inclination is to be strict in what we accept (i.e., exactly the 
"EPPS" string) until we find a reason otherwise.

Or, if you're gonna pull the strict compliance card, check all 6 
combinations, not just 1 of them.

Brian

[1] This is a totally made-up example. I do not understand at all why 
ONFI would allow anything besides exactly "EPPS".
--
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