linux-kernel - Re: [usb-storage] [PATCH] JMicron JM20337 USB-SATA data corruption bugfix

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: <20080730200033.GD7578@one-eyed-alien.net>
Date:	Wed, 30 Jul 2008 13:00:33 -0700
From:	Matthew Dharm <mdharm-kernel@...-eyed-alien.net>
To:	Robert Hancock <hancockr@...w.ca>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	usb-storage@...ts.one-eyed-alien.net,
	Tomas Styblo <tripie@...n.org>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [usb-storage] [PATCH] JMicron JM20337 USB-SATA data corruption bugfix - device 152d:2338

On Wed, Jul 30, 2008 at 01:55:25PM -0600, Robert Hancock wrote:
> Alan Stern wrote:
> > On Wed, 23 Jul 2008, Robert Hancock wrote:
> > 
> >> It remains an issue, though, that if there's no underflow, if the device 
> >> reports an error in the CSW but doesn't provide sense data, we assume 
> >> nothing bad happened and don't retry. That definitely does not seem 
> >> correct. The device is not supposed to do this, but with how crappily 
> >> some of these devices are designed we should be more defensive.
> > 
> > The problem is, what can you do?  The device has said that something 
> > was wrong, but it hasn't told you what.  Without knowing what went 
> > wrong, you can't know how to recover.

Yes and no.  If ASC/ASCQ is clear, then it's telling you that nothing is
wrong.  The device is contradicting itself. That doesn't really help us
here, but it's a point I like to be clear on.

> > I suppose in such cases we could simply report that the command failed
> > completely.
> 
> I think that is what we need to do. The SCSI/block layers should retry 
> the command or report a failure to userspace. Above all else we can't 
> just continue on our merry way and assume success, otherwise data will 
> get silently corrupted.

The code path to supress the reporting of an error when auto-sense shows no
ASC/ASCQ was added for a reason.  That reason has likely been lost to time,
but I worry about devices that are out there that rely on the current
behavior to function properly....

Matt

-- 
Matthew Dharm                              Home: mdharm-usb@...-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

A:  The most ironic oxymoron wins ...
DP: "Microsoft Works"
A:  Uh, okay, you win.
					-- A.J. & Dust Puppy
User Friendly, 1/18/1998

Content of type "application/pgp-signature" skipped