linux-kernel - Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache

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: <1317385117.2993.7.camel@dabdike.hansenpartnership.com>
Date:	Fri, 30 Sep 2011 07:18:37 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Amit Sahrawat <amit.sahrawat83@...il.com>
Cc:	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>
Subject: Re: BUG in kernel: Wrong Handling of USB HDD’s
 in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

On Fri, 2011-09-30 at 12:26 +0530, Amit Sahrawat wrote:
> Now, for the USB HDD which do have write cache - sginfo is showing
> them to Write Cache Enabled as false.
> Why do the result of hdparm identification and sginfo varies- (I know
> they have different interface to work with and hdparm takes care of
> that by using SG_IO interface from it's code)? hdparm showed me
> correct results - that lead me to digging in the kernel code and
> checking the performance for USB HDD with Write cache enabled/disabled
> - which also showed that QUEUE ordering chosen for USB HDD is not
> correct.

Well, what all this means is the SATL in the USB device is implemented
wrongly.  Since USB devices only preset SCSI interfaces, that's what we
have to believe.

hdparm when used correctly sends an ATA inquiry command wrapped in an
ATA_12 or ATA_16 SCSI command.  A large number of legacy SATLs are known
to crash on these commands.

Are you sure the ATA command is reporting correctly?  A write back cache
is a remarkably silly thing to enable for a USB device because they're
highly likely to be surprise ejected which powers the device down.

> I have a large number of USB HDD's - with different vendors, and for
> all of them - it is showing Write Cache Enabled as false.
> The code works only for the Pen Drives or the USB HDD which do not
> have internal cache.
> 
> Also, for journalling filesystem being used on USB HDD - it does
> becomes a cause of concern.
> 
> Please share your opinion, I guess we need a change for mode sensing
> in the kernel code for USB HDD.

Well that's a nastily complex problem.  It really needs to be
whitelisted in the USB stack, but if every drive is doing it, that's
quite a task.

The question becomes how do we detect in a SCSI fashion that the device
has a write back cache if none of the standard SCSI mechanisms reports
it?

James

--
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/