linux-kernel - RE: [PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA

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] [day] [month] [year] [list]

Date:	Thu, 15 Mar 2012 23:03:45 +0000
From:	KY Srinivasan <kys@...rosoft.com>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
CC:	Christoph Hellwig <hch@...radead.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"virtualization@...ts.osdl.org" <virtualization@...ts.osdl.org>,
	"ohering@...e.com" <ohering@...e.com>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
	Haiyang Zhang <haiyangz@...rosoft.com>
Subject: RE: [PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA_16 command
 to the host



> -----Original Message-----
> From: James Bottomley [mailto:James.Bottomley@...senPartnership.com]
> Sent: Sunday, March 04, 2012 9:49 AM
> To: KY Srinivasan
> Cc: Christoph Hellwig; gregkh@...uxfoundation.org; linux-
> kernel@...r.kernel.org; devel@...uxdriverproject.org;
> virtualization@...ts.osdl.org; ohering@...e.com; linux-scsi@...r.kernel.org;
> Haiyang Zhang
> Subject: RE: [PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA_16 command to
> the host
> 
> On Sun, 2012-03-04 at 14:23 +0000, KY Srinivasan wrote:
> >
> > > -----Original Message-----
> > > From: Christoph Hellwig [mailto:hch@...radead.org]
> > > Sent: Sunday, March 04, 2012 4:12 AM
> > > To: KY Srinivasan
> > > Cc: gregkh@...uxfoundation.org; linux-kernel@...r.kernel.org;
> > > devel@...uxdriverproject.org; virtualization@...ts.osdl.org;
> ohering@...e.com;
> > > jbottomley@...allels.com; hch@...radead.org; linux-scsi@...r.kernel.org;
> > > Haiyang Zhang
> > > Subject: Re: [PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA_16 command to
> > > the host
> > >
> > > On Fri, Mar 02, 2012 at 12:49:07PM -0800, K. Y. Srinivasan wrote:
> > > > Windows hosts don't handle the ATA_16 command; don't pass it to the
> host.
> > >
> > > Most devices don't handle it, and answer with and unsupported opcode
> > > sense reason.  If hyperv iis buggy enough to crap out on it please add
> > > a comment explaining that.
> >
> > The host does not "crap out", it does return an error code but it is not
> "unsupported opcode".
> > The sense reason that comes back is a generic error SRB_STATUS code. It is
> easier for me to filter the
> > command on the outgoing side as opposed to dealing with a generic error code
> that is coming back from
> > the host.
> 
> That's the wrong thing to do ... you need to unwrap the error code.
> The reason being I presume it's not impossible for Windows to host a
> device supporting ATA_16 and there are signs that this is going to be
> necessary to prevent data corruption on some USB devices ... if you just
> filter the command without checking if the host supports it, you're
> going to end up perpetuating the corruption problem.

James,

Currently, the Windows host does not provide me with granular error codes to 
distinguish between the case where the operation failed and the case where it is
an illegal or unsupported operation. I have asked the windows team to return more
appropriate error codes and they may do that sometime soon. In the interim, filtering
the command on the outgoing path is the best way I can deal with this issue. Currently,
even on the host side they are filtering this command, except they are returning a failure
to the guest instead of a more appropriate error code.
While my proposal has been accepted for windows 8, I don't know when this change will ship.
Also, it is not clear when prior versions of Windows hosts that we care about will pick up this
change. This patch is the only way I know how to deal with this problems within my current
constraints.

Regards,

K. Y


> 
> The general rule of thumb for avoiding this is to let the lower layers
> handle as much as possible, and only begin behaviour alterations in the
> upper layers if the lower layers have a provable and usually fatal
> failure.
> 
> James
> 
>