linux-kernel - Re: [PATCH repost 3] [SCSI] Retrieve the Caching mode page

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:	Wed, 24 Nov 2010 08:55:02 -0800 (PST)
From:	Luben Tuikov <ltuikov@...oo.com>
To:	James Bottomley <James.Bottomley@...e.de>
Cc:	Matthew Dharm <mdharm-kernel@...-eyed-alien.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
	linux-usb@...r.kernel.org, Greg KH <greg@...ah.com>
Subject: Re: [PATCH repost 3] [SCSI] Retrieve the Caching mode page

--- On Wed, 11/24/10, James Bottomley <James.Bottomley@...e.de> wrote:

> The basic problem isn't devices lying ... the worst we'll
> do is current
> behaviour (not SYNC when we should).  The problem is
> devices that get
> confused (or worse simply crash the firmware).  The
> best way to avoid
> the crashing firmware problem ... if we can assume that
> modern USB
> devices are better is to key off the SCSI version. 
> Unfortunately, in
> spite of several attempts, we've never managed to stop
> usbstorage lying
> about this:
> 
>         /* Some devices
> report a SCSI revision level above 2 but are
>          * unable
> to handle the REPORT LUNS command (for which
>          * support
> is mandatory at level 3).  Since we already have
>          * a
> Get-Max-LUN request, we won't lose much by setting the
>          * revision
> level down to 2.  The only devices that would be
>          * affected
> are those with sparse LUNs. */
>         if
> (sdev->scsi_level > SCSI_2)
>            
> sdev->sdev_target->scsi_level =
>            
>         sdev->scsi_level =
> SCSI_2;
> 
> Untangling all of this would be rather complex, I fear.

CBI/BBB isn't supposed to be, nor is designed to support SAM-modern devices. So while REQUEST LUN /may/ work on some devices which implement it in their firmware, it is NOT a requirement for those devices as they are not required to adhere to any SAM version. Those transport protocols define a class-specific request to get the maximum LUN, and another to reset the target port (instead of I_T Reset or LU Reset). They also do not support SCSI Status completion of the command, nor Autosense. They also do not provide TMFs. They provide none of the SCSI transport protocol services in support of the Execute Command procedure call. The SCSI layer shouldn't be trying to guess their "SCSI version", and or treat them as real SCSI devices sending REPORT LUNs, etc. commands.

Newer, modern transport protocols over USB, are part of SAM, and it is devices who connect via those protocols that are being disadvantaged, due to the adoption (assumption) of CBI/BBB well into the SCSI layer.

To this effect, the transport protocol can tell upper layers if the device is true SCSI (new usb transports or other) or hybrid (usb-storage). In the former case, the device is a SCSI device, in the latter, only basic commands should be attempted.

This isn't to say that firmware for those devices wouldn't be buggy. Of course it will, and most will probably port their legacy FW over to the new SPTL, but the protocol requirements are there by design (i.e. there is no longer Get Max Lun class-specific request, the application client has to send REPORT LUNS, and FW has to answer it) and we have to accommodate that.

It is in this spirit that this patch doesn't change wire behavior, but simply parses data returned by a command already supported by older protocols.

     Luben

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