linux-kernel - Re: [PATCH] mmc_spi: use EILSEQ for possible transmission errors

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: <200905191347.46026.wolfgang.mues@auerswald.de>
Date:	Tue, 19 May 2009 13:47:45 +0200
From:	Wolfgang Mües <wolfgang.mues@...rswald.de>
To:	"Matt Fleming" <matt@...sole-pimps.org>
Cc:	"Pierre Ossman" <drzeus@...eus.cx>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"David Brownell" <dbrownell@...rs.sourceforge.net>,
	"Mike Frysinger" <vapier.adi@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mmc_spi: use EILSEQ for possible transmission errors

Matt,

Am Dienstag, 19. Mai 2009 schrieb Matt Fleming:
> On Thu, May 14, 2009 at 12:24:27PM +0100, Wolfgang Mües wrote:
> > o This patch changes the reported error code for the responses
> >   to a command from EINVAL/EIO to EILSEQ

> Hmm, always returning -EILSEQ is devious. What happens if we sent an
> illegal command?
Isn't this a theoretical question?
Sending an illegal command will never work. Even the programmer of this piece 
of software will notice, and such a software will not find it's way into the 
kernel.

And IF it would, and really it's an illegal command, then it does no harm if 
it is retried several times. It will never work.

Matt, I do not like this patch either.

But given the fact that a response is NOT checksum-protected, there is NO WAY 
we can tell if the received response is a transmission error or a real error 
code from the SD/MMC card.

My first patch has not changed the error codes in mmc_spi, but only changed 
the actions in block.c.

But Pierre has objected against this: he stated that EINVAL is used by all 
(non-SPI) drivers only for true non-recoverable errors, and requested that 
another error code should be used by the mmc_spi driver. The apropriate code 
for transmission errors is EILSEQ.

Maybe a solution-in-the-middle is to use different error codes in the mmc_spi 
framework, which allows to differentiate between individual response codes, 
and treat them all as transmission errors in block.c. What error codes can we 
choose?

> IMHO always assuming that command errors are caused by transmission
> problems is not the right solution.

It's not your or my fault, it's the fault of the spi SD/MMC card protocol 
designer. You may send him to me, already prepared: naked and in chains ;-)

regards

i. A. Wolfgang Mües
-- 
Auerswald GmbH & Co. KG
Hardware Development
Telefon: +49 (0)5306 9219 0
Telefax: +49 (0)5306 9219 94 
E-Mail: Wolfgang.Mues@...rswald.de
Web: http://www.auerswald.de

--------------------------------------------------------------
Auerswald GmbH & Co. KG, Vor den Grashöfen 1, 38162 Cremlingen
Registriert beim AG Braunschweig HRA 13289
p.h.G Auerswald Geschäftsführungsges. mbH
Registriert beim AG Braunschweig HRB 7463
Geschäftsführer: Dipl-Ing. Gerhard Auerswald
--
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/