Accessing disabled SCSI devices via Storport

I am developing the SCSI device test application. It is intended mainly for
SCSI device firmware developers and testers, and allows user to execute
manually any SCSI command for the selected SCSI device. During the
development and testing of the firmware the device might not be able to
answer properly to SCSI commands. In this case it is necessary to disable the
device object in the Device Manger window. Disabling the device object
prevents the class driver from sending the SCSI commands for normal
functioning. The special pseudo class driver was developed for the
transparent device access. This driver sends IRP_MJ_SCSI IRPs with the SRBs
directly to storage adapter objects (Scsi0:, Scsi1:, etc). This worked fine
with SCSI Port but does not work with Storport. As I have learned from this
newsgroup the Storport does not allow sending SRBs directly to adapter
object. Sending SRBs to SCSI device object works fine but when the device is
disabled there is no device object at all. The SCSI PASS THROUGH interface
also does not work through the Storport for the disabled SCSI device.

Is there a way to send the SCSI command to the disabled SCSI device via the
Storport?

Thanks a lot for advice.

Mark
Mon Oct 15 12:15:03 PDT 2007

Andriy Chobik wrote:
> I am developing the SCSI device test application. It is intended mainly for
> SCSI device firmware developers and testers, and allows user to execute
> manually any SCSI command for the selected SCSI device. During the
> development and testing of the firmware the device might not be able to
> answer properly to SCSI commands. In this case it is necessary to disable the
> device object in the Device Manger window. Disabling the device object
> prevents the class driver from sending the SCSI commands for normal
> functioning. The special pseudo class driver was developed for the
> transparent device access. This driver sends IRP_MJ_SCSI IRPs with the SRBs
> directly to storage adapter objects (Scsi0:, Scsi1:, etc). This worked fine
> with SCSI Port but does not work with Storport. As I have learned from this
> newsgroup the Storport does not allow sending SRBs directly to adapter
> object. Sending SRBs to SCSI device object works fine but when the device is
> disabled there is no device object at all. The SCSI PASS THROUGH interface
> also does not work through the Storport for the disabled SCSI device.
>
> Is there a way to send the SCSI command to the disabled SCSI device via the
> Storport?
>
> Thanks a lot for advice.

I think you answered your own question: storport by design (for some
versions of storport) does not allow sending SPT requests to luns
through the adapter object. I would question your assumption that "it is
necessary to disable the device object". Why is it necessary? Does the
test/development system crash if these devices are not disabled?

If you really have to disable the devices, then perhaps instead you
could write a scsi bus filter driver to control access to scsi bus
adapter (storport or scsiport) enumerated PDOs of any type, and to
provide an access mechanism for your test applications. PnP bus filter
drivers are of course undocumented and unsupported but they have been
discussed here before, along with outlines of their general implementation.

AndriyChobik
Wed Oct 17 09:28:04 PDT 2007

Thanks for your answer.

I think that it is correct design to not allow accessing the disabled
devices. If this is possible one can easily read and write the contents of
disk because there is no driver stack that implements certain policies. This
is a real security hole.

The requirement is to be able to control sending of every SCSI command to
the device. This is like step by step debugging when the developer executes
one statement at time and looks at the result.

Another idea just came to my mind. One can develop pseudo class driver that
do not expose device type specific (disk, tape, etc) functionality to OS but
simply allows the test application to suitably send the SCSI commands to the
device. If there is no OS class driver installed for the device the test
application can install the pseudo class driver. If the device type specific
class driver is already installed the test application can simply reassign
the pseudo class driver to the device. In this scenario the device will be
switched to the so-called test mode. When the developer is done with the
debugging and testing one can switch the device back to normal operation
mode. This scenario does not require the device to be disabled.

Mark
Wed Oct 17 10:00:01 PDT 2007

Andriy Chobik wrote:
> Thanks for your answer.
>
> I think that it is correct design to not allow accessing the disabled
> devices. If this is possible one can easily read and write the contents of
> disk because there is no driver stack that implements certain policies. This
> is a real security hole.
>

I must have misunderstood. I thought you were discussing a test and
development environment where this sort of security hole would not be a
problem. If the device identifies itself as a disk then it will be
controlled by disk.sys, even if it does not otherwise behave correctly.


> The requirement is to be able to control sending of every SCSI command to
> the device. This is like step by step debugging when the developer executes
> one statement at time and looks at the result.
>
> Another idea just came to my mind. One can develop pseudo class driver that
> do not expose device type specific (disk, tape, etc) functionality to OS but
> simply allows the test application to suitably send the SCSI commands to the
> device. If there is no OS class driver installed for the device the test
> application can install the pseudo class driver. If the device type specific
> class driver is already installed the test application can simply reassign
> the pseudo class driver to the device. In this scenario the device will be
> switched to the so-called test mode. When the developer is done with the
> debugging and testing one can switch the device back to normal operation
> mode. This scenario does not require the device to be disabled.

That should work. You will have to deal with convincing PnP to associate
the device under test with your driver rather than, for example,
disk.sys, but that can be done.

Gary
Mon Oct 22 06:58:46 PDT 2007

It do and it does work quite well. We have a series of diagnostic drivers
from SiI 680, SiI 3214, a few on mother-board control chips and the LSI
SCSI, SAS and FC family of controllers using our own Class GUID. We do this
for diagnostic purposes only since we like to know if our drives work, and
many times the file systems and storage stacks of Windows and or Linux
simply get in the way, and do not allow a the range of SCSI or ATA testing..

--
The personal opinion of
Gary G. Little

"Mark Roddy" <markr@hollistech.com> wrote in message
news:u9Jyo8NEIHA.5324@TK2MSFTNGP02.phx.gbl...
> Andriy Chobik wrote:
>> Thanks for your answer.
>>
>> I think that it is correct design to not allow accessing the disabled
>> devices. If this is possible one can easily read and write the contents
>> of disk because there is no driver stack that implements certain
>> policies. This is a real security hole.
>>
>
> I must have misunderstood. I thought you were discussing a test and
> development environment where this sort of security hole would not be a
> problem. If the device identifies itself as a disk then it will be
> controlled by disk.sys, even if it does not otherwise behave correctly.
>
>
>> The requirement is to be able to control sending of every SCSI command to
>> the device. This is like step by step debugging when the developer
>> executes one statement at time and looks at the result.
>>
>> Another idea just came to my mind. One can develop pseudo class driver
>> that do not expose device type specific (disk, tape, etc) functionality
>> to OS but simply allows the test application to suitably send the SCSI
>> commands to the device. If there is no OS class driver installed for the
>> device the test application can install the pseudo class driver. If the
>> device type specific class driver is already installed the test
>> application can simply reassign the pseudo class driver to the device. In
>> this scenario the device will be switched to the so-called test mode.
>> When the developer is done with the debugging and testing one can switch
>> the device back to normal operation mode. This scenario does not require
>> the device to be disabled.
>
> That should work. You will have to deal with convincing PnP to associate
> the device under test with your driver rather than, for example, disk.sys,
> but that can be done.
>