Disk accesses

NTDEV
1

Can someone explain why there are so many different ways to send the same
SCSI request to a disk?? IRP_MJ_SCSI w/ no or some undocumented IOCT codes,
or IRP_MJ_INTERNAL_DEVICE_CONTROL (or is that actually IRP_MJ_SCSI again??)
w/: IOCTL_SCSI_EXECUTE_IN, IOCTL_SCSI_PASS_THROUGH, or
IOCTL_SCSI_PASS_THROUGH_DIRECT.

Oh, and you may get a SCSI_REQUEST_BLOCK or no wait is that a
SCSI_PASS_THROUGH_DIRECT structure? I know let’s not make them overlap so
everyone can just duplicate code all over.

I know I am probably late to the game on this…but is there a rhyme or
reason to this lovely architecture? Did I miss some documentation
somewhere?

I would love to know the *why* of all of this.

Bill M.

2

IRP_MJ_SCSI == IRP_MJ_INTERNAL_DEVICE_CONTROL. This is easily determined by looking at the headers. No SCSI shouldn’t have its own IRP MJ code, and no it shouldn’t reuse a number from an existing one. But it’s been that way since I joined MS (and I tried to change it once … not possible without breaking everyone doing storage) and so we all just have to live with it. Someone decided we needed a MJ code for SCSI requests. I suspect IRP_MJ_INTERNAL_DEVICE_CONTROL was reused to avoid the cost of an additional PVOID per driver object (which at the time would have been an issue).

IOCTL_SCSI_EXECUTE_* is set in the stack location for an IRP_MJ_SCSI to (a) allow someone handling IRP_MJ_INTERNAL_DEVICE_CONTROL to differentiate between the two and (b) to provide some indicator of which direction the SRB is transferring data. Its use isn’t particularly consistent … I think of it as more of a debugging aid but I see that some of our drivers (like the RAMDISK driver) use it to decide if the SRB in question is a read/write type command or one of those strange SCSI commands like REQUEST_SENSE which require more complex emulation. I think using the CDB code would have been a much better idea.

IRP_MJ_SCSI comes with an SRB.

IOCTL_SCSI_PASS_THROUGH and IOCTL_SCSI_PASS_THROUGH_DIRECT are to send SCSI requests from user-mode. They come with SCSI_PASS_THROUGH/SCSI_PASS_THROUGH_DIRECT structures so as not to expose SRB to user-mode and so as to avoid validating SRBs which might come from user-mode. Besides, how is a user mode component going to provide a value like OriginalIrp. IOCTL_SCSI_PASS_THROUGH is a buffered operation, while IOCTL_SCSI_PASS_THROUGH_DIRECT direct maps the data transfer. They’re separate control codes because they are - I suppose a flag in the PASS_THROUGH structure could have contained the transfer mode … would that make you happier?

So there are two ways to send a SCSI request. One for kernel-mode components (IRP_MJ_SCSI) and one for user-mode components (IOCTL_SCSI_PASS_THROUGH[_DIRECT]). If you want to convert a pass-through command to a IRP_MJ_SCSI command it’s pretty straight-forward to make an SRB and send it down. I bet you could even do it without “duplicat[ing] code all over” if you tried. This is how the SCSI port drivers deal with it - validate the parameters, build an SRB and then push that in through the code that handles SRBs.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Friday, January 25, 2008 3:13 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Disk accesses

Can someone explain why there are so many different ways to send the same
SCSI request to a disk?? IRP_MJ_SCSI w/ no or some undocumented IOCT codes,
or IRP_MJ_INTERNAL_DEVICE_CONTROL (or is that actually IRP_MJ_SCSI again??)
w/: IOCTL_SCSI_EXECUTE_IN, IOCTL_SCSI_PASS_THROUGH, or
IOCTL_SCSI_PASS_THROUGH_DIRECT.

Oh, and you may get a SCSI_REQUEST_BLOCK or no wait is that a
SCSI_PASS_THROUGH_DIRECT structure? I know let’s not make them overlap so
everyone can just duplicate code all over.

I know I am probably late to the game on this…but is there a rhyme or
reason to this lovely architecture? Did I miss some documentation
somewhere?

I would love to know the *why* of all of this.

Bill M.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

It is certainly an interesting architecture :slight_smile: Evolved is the most generous
thing one can say about it.

IOCTL_SCSI_EXECUTE_IN: beats me - as we learned earlier some sort of
cdromish thing. I only do disks.
IRP_MJ_SCSI aka IRP_MJ_INTERNAL_DEVICE_CONTROL: how class level devices talk
to port level scsi devices. Cannot be sent from user mode, other kernel
components can cheat. There are some differences in how scsiport handles
these requests compared to IOCTL_SCSI_PASS_THROUGH, or
IOCTL_SCSI_PASS_THROUGH_DIRECT which are the two methods supplied for user
mode to send SRBs to scsiport directly, one using buffered io the other
using an mdl. Offhand I cannot remember exactly how scsiport mistreats pass
through requests compared to IRP_MJ_SCSI, but it does. I think perhaps only
one at a time per hba is permitted to be in flight on the hba. I could be
wrong.

Oh now you want documentation?

On Jan 25, 2008 6:12 PM, Bill McKenzie wrote:

> Can someone explain why there are so many different ways to send the same
> SCSI request to a disk?? IRP_MJ_SCSI w/ no or some undocumented IOCT
> codes,
> or IRP_MJ_INTERNAL_DEVICE_CONTROL (or is that actually IRP_MJ_SCSI
> again??)
> w/: IOCTL_SCSI_EXECUTE_IN, IOCTL_SCSI_PASS_THROUGH, or
> IOCTL_SCSI_PASS_THROUGH_DIRECT.
>
> Oh, and you may get a SCSI_REQUEST_BLOCK or no wait is that a
> SCSI_PASS_THROUGH_DIRECT structure? I know let’s not make them overlap so
> everyone can just duplicate code all over.
>
> I know I am probably late to the game on this…but is there a rhyme or
> reason to this lovely architecture? Did I miss some documentation
> somewhere?
>
> I would love to know the why of all of this.
>
> Bill M.
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

–
Mark Roddy

4

Miniport IOCTLs are one per time at the HBA level, but I don’t think passthrough requests are. The class driver may reject pass-through requests (in particular they used to block 3rd party copy commands). And IIRC I think pass-through commands are sent untagged - perhaps that’s the “mistreating” you’re thinking of?

-p

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Friday, January 25, 2008 7:14 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Disk accesses

It is certainly an interesting architecture :slight_smile: Evolved is the most generous thing one can say about it.

IOCTL_SCSI_EXECUTE_IN: beats me - as we learned earlier some sort of cdromish thing. I only do disks.
IRP_MJ_SCSI aka IRP_MJ_INTERNAL_DEVICE_CONTROL: how class level devices talk to port level scsi devices. Cannot be sent from user mode, other kernel components can cheat. There are some differences in how scsiport handles these requests compared to IOCTL_SCSI_PASS_THROUGH, or IOCTL_SCSI_PASS_THROUGH_DIRECT which are the two methods supplied for user mode to send SRBs to scsiport directly, one using buffered io the other using an mdl. Offhand I cannot remember exactly how scsiport mistreats pass through requests compared to IRP_MJ_SCSI, but it does. I think perhaps only one at a time per hba is permitted to be in flight on the hba. I could be wrong.

Oh now you want documentation?

On Jan 25, 2008 6:12 PM, Bill McKenzie > wrote:
Can someone explain why there are so many different ways to send the same
SCSI request to a disk?? IRP_MJ_SCSI w/ no or some undocumented IOCT codes,
or IRP_MJ_INTERNAL_DEVICE_CONTROL (or is that actually IRP_MJ_SCSI again??)
w/: IOCTL_SCSI_EXECUTE_IN, IOCTL_SCSI_PASS_THROUGH, or
IOCTL_SCSI_PASS_THROUGH_DIRECT.

Oh, and you may get a SCSI_REQUEST_BLOCK or no wait is that a
SCSI_PASS_THROUGH_DIRECT structure? I know let’s not make them overlap so
everyone can just duplicate code all over.

I know I am probably late to the game on this…but is there a rhyme or
reason to this lovely architecture? Did I miss some documentation
somewhere?

I would love to know the why of all of this.

Bill M.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

–
Mark Roddy — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

5

> IRP_MJ_SCSI == IRP_MJ_INTERNAL_DEVICE_CONTROL. This is easily determined

by looking at the headers

Yeah except equal isn’t really equal right :slight_smile:

so we all just have to live with it

I don’t mind that we have a legacy situation, but it might be helpful to
know exactly what we have to live with.

IOCTL_SCSI_EXECUTE_* is set in the stack location for an IRP_MJ_SCSI to
(a) allow someone handling
IRP_MJ_INTERNAL_DEVICE_CONTROL to differentiate between the two

Except that it isn’t. I see numerous IRP_MJ_SCSI, or
IRP_MJ_INTERNAL_DEVICE_CONTROL requests come in with 0 for the
IoControlCode, but they have a valid SRB on board. I assumed that
IRP_MJ_SCSI required one to zero out the IoControlCode and
IRP_MJ_INTERNAL_DEVICE_CONTROL used the IOCTL_SCSI_* to indicate there was
an SRB on board. I guess I assumed somewhat incorrectly? What added to my
confusion was the discussion here:
http://www.osronline.com/showThread.cfm?link=75130 where they used
IoBuildDeviceIoControl to send an IOCTL_SCSI_EXECUTE_IN request.

Interestingly enough, I see IoControlCode == 1 in one stack on Vista64 on my
target machine. So, I am stuck just checking for a SRB if I receive an
IoControlCode I don’t recognize. Hmmm, that actually does NOT make me
happy.

and (b) to provide some indicator of which direction the SRB is
transferring data.
Its use isn’t particularly consistent …

With all the documentation that is quite a surprise :slight_smile:

They come with SCSI_PASS_THROUGH/SCSI_PASS_THROUGH_DIRECT structures so as
not to expose SRB to user-mode and so as to avoid
validating SRBs which might come from user-mode. Besides, how is a user
mode component going to provide a value like OriginalIrp

I guess what I would have expected here is the IO manager to do a similar
job as it does for other I/O requests. I mean, IRPs aren’t exposed to
user-mode either, but buffers are validated and IRPs created for
DeviceIoControl calls. I would expect the IO Manager to see that a
SCSI_PASS_THROUGH_* request is coming down, and to create an SRB on behalf
of the driver to keep the code paths sane and clean. Again, it is what it
is (although this might could be changed without breaking anyone?) but I
was curious if what I am seeing is what it is. I was close and good enough
for my purposes.

What also added to my confusion is three separate CD-ROM burning
applications all burning the same data to writable CD-R media, but all using
different I/O request paths. It makes one wonder why, thus my question.

Thanks much for your response btw!

Bill M.

“Peter Wieland” wrote in message
news:xxxxx@ntdev…
IRP_MJ_SCSI == IRP_MJ_INTERNAL_DEVICE_CONTROL. This is easily determined by
looking at the headers. No SCSI shouldn’t have its own IRP MJ code, and no
it shouldn’t reuse a number from an existing one. But it’s been that way
since I joined MS (and I tried to change it once … not possible without
breaking everyone doing storage) and so we all just have to live with it.
Someone decided we needed a MJ code for SCSI requests. I suspect
IRP_MJ_INTERNAL_DEVICE_CONTROL was reused to avoid the cost of an additional
PVOID per driver object (which at the time would have been an issue).

IOCTL_SCSI_EXECUTE_* is set in the stack location for an IRP_MJ_SCSI to (a)
allow someone handling IRP_MJ_INTERNAL_DEVICE_CONTROL to differentiate
between the two and (b) to provide some indicator of which direction the SRB
is transferring data. Its use isn’t particularly consistent … I think of
it as more of a debugging aid but I see that some of our drivers (like the
RAMDISK driver) use it to decide if the SRB in question is a read/write type
command or one of those strange SCSI commands like REQUEST_SENSE which
require more complex emulation. I think using the CDB code would have been
a much better idea.

IRP_MJ_SCSI comes with an SRB.

IOCTL_SCSI_PASS_THROUGH and IOCTL_SCSI_PASS_THROUGH_DIRECT are to send SCSI
requests from user-mode. They come with
SCSI_PASS_THROUGH/SCSI_PASS_THROUGH_DIRECT structures so as not to expose
SRB to user-mode and so as to avoid validating SRBs which might come from
user-mode. Besides, how is a user mode component going to provide a value
like OriginalIrp. IOCTL_SCSI_PASS_THROUGH is a buffered operation, while
IOCTL_SCSI_PASS_THROUGH_DIRECT direct maps the data transfer. They’re
separate control codes because they are - I suppose a flag in the
PASS_THROUGH structure could have contained the transfer mode … would that
make you happier?

So there are two ways to send a SCSI request. One for kernel-mode
components (IRP_MJ_SCSI) and one for user-mode components
(IOCTL_SCSI_PASS_THROUGH[_DIRECT]). If you want to convert a pass-through
command to a IRP_MJ_SCSI command it’s pretty straight-forward to make an SRB
and send it down. I bet you could even do it without “duplicat[ing] code
all over” if you tried. This is how the SCSI port drivers deal with it -
validate the parameters, build an SRB and then push that in through the code
that handles SRBs.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Friday, January 25, 2008 3:13 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Disk accesses

Can someone explain why there are so many different ways to send the same
SCSI request to a disk?? IRP_MJ_SCSI w/ no or some undocumented IOCT codes,
or IRP_MJ_INTERNAL_DEVICE_CONTROL (or is that actually IRP_MJ_SCSI again??)
w/: IOCTL_SCSI_EXECUTE_IN, IOCTL_SCSI_PASS_THROUGH, or
IOCTL_SCSI_PASS_THROUGH_DIRECT.

Oh, and you may get a SCSI_REQUEST_BLOCK or no wait is that a
SCSI_PASS_THROUGH_DIRECT structure? I know let’s not make them overlap so
everyone can just duplicate code all over.

I know I am probably late to the game on this…but is there a rhyme or
reason to this lovely architecture? Did I miss some documentation
somewhere?

I would love to know the why of all of this.

Bill M.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

6

One other confusion here is I see IOCTL_SCSI_PASS_THROUGH_DIRECT requests coming from the redbook driver. How is that happening? Is there an interface for reading and writing data to media through this driver? Is this documented? Is that secure?

Bill M.
“Peter Wieland” wrote in message news:xxxxx@ntdev…
Miniport IOCTLs are one per time at the HBA level, but I don’t think passthrough requests are. The class driver may reject pass-through requests (in particular they used to block 3rd party copy commands). And IIRC I think pass-through commands are sent untagged - perhaps that’s the “mistreating” you’re thinking of?

-p

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Friday, January 25, 2008 7:14 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Disk accesses

It is certainly an interesting architecture :slight_smile: Evolved is the most generous thing one can say about it.

IOCTL_SCSI_EXECUTE_IN: beats me - as we learned earlier some sort of cdromish thing. I only do disks.

IRP_MJ_SCSI aka IRP_MJ_INTERNAL_DEVICE_CONTROL: how class level devices talk to port level scsi devices. Cannot be sent from user mode, other kernel components can cheat. There are some differences in how scsiport handles these requests compared to IOCTL_SCSI_PASS_THROUGH, or IOCTL_SCSI_PASS_THROUGH_DIRECT which are the two methods supplied for user mode to send SRBs to scsiport directly, one using buffered io the other using an mdl. Offhand I cannot remember exactly how scsiport mistreats pass through requests compared to IRP_MJ_SCSI, but it does. I think perhaps only one at a time per hba is permitted to be in flight on the hba. I could be wrong.

Oh now you want documentation?

On Jan 25, 2008 6:12 PM, Bill McKenzie wrote:

Can someone explain why there are so many different ways to send the same
SCSI request to a disk?? IRP_MJ_SCSI w/ no or some undocumented IOCT codes,
or IRP_MJ_INTERNAL_DEVICE_CONTROL (or is that actually IRP_MJ_SCSI again??)
w/: IOCTL_SCSI_EXECUTE_IN, IOCTL_SCSI_PASS_THROUGH, or
IOCTL_SCSI_PASS_THROUGH_DIRECT.

Oh, and you may get a SCSI_REQUEST_BLOCK or no wait is that a
SCSI_PASS_THROUGH_DIRECT structure? I know let’s not make them overlap so
everyone can just duplicate code all over.

I know I am probably late to the game on this…but is there a rhyme or
reason to this lovely architecture? Did I miss some documentation
somewhere?

I would love to know the why of all of this.

Bill M.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

–
Mark Roddy — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

7

Actually, my description below didn’t make sense. I am seeing the pass through requests come through the redbook driver, which I know is an upper filter of the cdrom driver, which means the requests came from user-mode down through the stack as expected. I guess my confusion was security. I didn’t know you could read/write a CD via these IOCTLs from user-mode, but I guess someone has to be able to write to the media :slight_smile: I suppose as long as the user-mode component is a service, or an app with appropriate privileges then all is well.

Interestingly enough, I see one nice commercial CD burning app completely circumventing the CDROM IO stack by calling directly from user-mode into its own cdrom.sys lower filter driver and calling from there directly into the PDO with data. I now know one application that will never see my dev machine :slight_smile:

Bill M.
“Bill McKenzie” wrote in message news:xxxxx@ntdev…
One other confusion here is I see IOCTL_SCSI_PASS_THROUGH_DIRECT requests coming from the redbook driver. How is that happening? Is there an interface for reading and writing data to media through this driver? Is this documented? Is that secure?

Bill M.
“Peter Wieland” wrote in message news:xxxxx@ntdev…
Miniport IOCTLs are one per time at the HBA level, but I don’t think passthrough requests are. The class driver may reject pass-through requests (in particular they used to block 3rd party copy commands). And IIRC I think pass-through commands are sent untagged - perhaps that’s the “mistreating” you’re thinking of?

-p

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Friday, January 25, 2008 7:14 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Disk accesses

It is certainly an interesting architecture :slight_smile: Evolved is the most generous thing one can say about it.

IOCTL_SCSI_EXECUTE_IN: beats me - as we learned earlier some sort of cdromish thing. I only do disks.

IRP_MJ_SCSI aka IRP_MJ_INTERNAL_DEVICE_CONTROL: how class level devices talk to port level scsi devices. Cannot be sent from user mode, other kernel components can cheat. There are some differences in how scsiport handles these requests compared to IOCTL_SCSI_PASS_THROUGH, or IOCTL_SCSI_PASS_THROUGH_DIRECT which are the two methods supplied for user mode to send SRBs to scsiport directly, one using buffered io the other using an mdl. Offhand I cannot remember exactly how scsiport mistreats pass through requests compared to IRP_MJ_SCSI, but it does. I think perhaps only one at a time per hba is permitted to be in flight on the hba. I could be wrong.

Oh now you want documentation?

On Jan 25, 2008 6:12 PM, Bill McKenzie wrote:

Can someone explain why there are so many different ways to send the same
SCSI request to a disk?? IRP_MJ_SCSI w/ no or some undocumented IOCT codes,
or IRP_MJ_INTERNAL_DEVICE_CONTROL (or is that actually IRP_MJ_SCSI again??)
w/: IOCTL_SCSI_EXECUTE_IN, IOCTL_SCSI_PASS_THROUGH, or
IOCTL_SCSI_PASS_THROUGH_DIRECT.

Oh, and you may get a SCSI_REQUEST_BLOCK or no wait is that a
SCSI_PASS_THROUGH_DIRECT structure? I know let’s not make them overlap so
everyone can just duplicate code all over.

I know I am probably late to the game on this…but is there a rhyme or
reason to this lovely architecture? Did I miss some documentation
somewhere?

I would love to know the why of all of this.

Bill M.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

–
Mark Roddy — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

8

Careful, somebody who reads this list has a conniption whenever this bit of
ugliness is pointed out.

On Jan 26, 2008 5:03 AM, Bill McKenzie wrote:

>
> Interestingly enough, I see one nice commercial CD burning app completely
> circumventing the CDROM IO stack by calling directly from user-mode into its
> own cdrom.sys lower filter driver and calling from there directly into the
> PDO with data. I now know one application that will never see my dev
> machine :slight_smile:
>
> –
> Mark Roddy
>

9

Mark Roddy wrote:

Careful, somebody who reads this list has a conniption whenever this
bit of ugliness is pointed out.

Anton K.?

10

>Interestingly enough, I see one nice commercial CD burning app completely

circumventing the CDROM IO stack by calling directly from user-mode into its
own
cdrom.sys lower filter driver

This is how IMAPI works.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

11

Yeah except this isn’t IMAPI (I guess Microsoft can break their own
rules)…this is a rather popular 3rd party CD/DVD burning program. I sat
there trying to ponder why anyone would do such a thing and I came up with
that they didn’t know what they were doing and were able to get this kludge
to work. That or they just wanted to prevent any pesky filter drivers from
being able to filter their data easily (although that doesn’t work :slight_smile:

Then I installed their product on Vista64 and found that they use a
different driver binary?? AND, they don’t do this nastyness with calling
straight into the PDO on Vista64. This adds credence to the “didn’t know
what they were doing” theory?

Bill M.

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> >Interestingly enough, I see one nice commercial CD burning app completely
>>circumventing the CDROM IO stack by calling directly from user-mode into
>>its
> own
>>cdrom.sys lower filter driver
>
> This is how IMAPI works.
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>

12

When I said binary below, I meant a driver with different name and
presumably built from different source, of course 64-bit has a different
binary. But, their 64-bit binary behaves differently than the 32-bit
version suggesting they possibly use two code bases. That seems odd, anyway
the way I stated that wasn’t really correct and clear.

Bill M.

“Bill McKenzie” wrote in message
news:xxxxx@ntdev…
> Yeah except this isn’t IMAPI (I guess Microsoft can break their own
> rules)…this is a rather popular 3rd party CD/DVD burning program. I sat
> there trying to ponder why anyone would do such a thing and I came up with
> that they didn’t know what they were doing and were able to get this
> kludge to work. That or they just wanted to prevent any pesky filter
> drivers from being able to filter their data easily (although that doesn’t
> work :slight_smile:
>
> Then I installed their product on Vista64 and found that they use a
> different driver binary?? AND, they don’t do this nastyness with calling
> straight into the PDO on Vista64. This adds credence to the “didn’t know
> what they were doing” theory?
>
> Bill M.
>
> “Maxim S. Shatskih” wrote in message
> news:xxxxx@ntdev…
>> >Interestingly enough, I see one nice commercial CD burning app
>> >completely
>>>circumventing the CDROM IO stack by calling directly from user-mode into
>>>its
>> own
>>>cdrom.sys lower filter driver
>>
>> This is how IMAPI works.
>>
>> –
>> Maxim Shatskih, Windows DDK MVP
>> StorageCraft Corporation
>> xxxxx@storagecraft.com
>> http://www.storagecraft.com
>>
>>
>
>
>

13

(why the obscurity about the product name?)

You’re not talking about Alcohol by any chance, are you? They do some WONDERFULLY complicated things to bypass just about everything in the CD-ROM stack. It’s really some very good hackery.

Of course, their approach is very deliberate. Something about DRM, I suppose.

Peter
OSR

14

No…Roxio…formerly Sonic Solutions, their Roxio Creator 10 product. Just
didn’t know how you guys felt about me putting the name out here.

Bill M.

wrote in message news:xxxxx@ntdev…
> (why the obscurity about the product name?)
>
> You’re not talking about Alcohol by any chance, are you? They do some
> WONDERFULLY complicated things to bypass just about everything in the
> CD-ROM stack. It’s really some very good hackery.
>
> Of course, their approach is very deliberate. Something about DRM, I
> suppose.
>
> Peter
> OSR
>
>

15

More detail:

Their PxHelp20.sys driver, which is a lower class filter to the CDROM class,
creates a sideband device object which they open from their user mode
application. They send data directly from user-mode to this filter driver
and the filter driver subsequently calls directly into the CdRom PDO with
the data. So, they essentially bypass the entire CDROM I/O stack. But on
Vista 64 they use a similar filter driver called PxHlpa64.sys which does NOT
call directly into the PDO, but can be filtered normally. I didn’t pay
attention to whether this driver creates a sideband device object or not and
I won’t have access to that machine this week to check.

Bill M.

“Bill McKenzie” wrote in message
news:xxxxx@ntdev…
> No…Roxio…formerly Sonic Solutions, their Roxio Creator 10 product.
> Just didn’t know how you guys felt about me putting the name out here.
>
> Bill M.
>
>
> wrote in message news:xxxxx@ntdev…
>> (why the obscurity about the product name?)
>>
>> You’re not talking about Alcohol by any chance, are you? They do some
>> WONDERFULLY complicated things to bypass just about everything in the
>> CD-ROM stack. It’s really some very good hackery.
>>
>> Of course, their approach is very deliberate. Something about DRM, I
>> suppose.
>>
>> Peter
>> OSR
>>
>>
>
>
>

16

Nothing to do with the DRM at all. Impossibility to trace the SCSI traffic (and reverse-engineer some
particular features) issued to the burner is only a tiny side effect. Main reason is - completely bypass
all the broken SCSI filters (Roxio, BlindWrite, ElbyCDIO, AnyDVD etc) people keep ignoring to fix for years.

For example AnyDVD (HD edition) has a bug mangling GET_CONFIGURATON command response. So it (absolutely
occasionally) turns HD DVD support OFF for a complete system. Except the guys who sit below AnyDVD filter
and talk directly to their own driver *guaranteed* to be layered above SCSI port.

Regards,
Anton Kolomyeytsev

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Sunday, January 27, 2008 9:40 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Disk accesses

(why the obscurity about the product name?)

You’re not talking about Alcohol by any chance, are you? They do some WONDERFULLY complicated things to bypass just about everything in the CD-ROM stack. It’s really some very good hackery.

Of course, their approach is very deliberate. Something about DRM, I suppose.

Peter
OSR

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

17

Inine.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Saturday, January 26, 2008 1:20 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Disk accesses

> so we all just have to live with it

I don’t mind that we have a legacy situation, but it might be helpful to
know exactly what we have to live with.

> IOCTL_SCSI_EXECUTE_* is set in the stack location for an IRP_MJ_SCSI to
> (a) allow someone handling
> IRP_MJ_INTERNAL_DEVICE_CONTROL to differentiate between the two

Except that it isn’t. I see numerous IRP_MJ_SCSI, or

See the note after that where I mention that it’s not consistently used.

There is not a good way to distinguish between IRP_MJ_INTERNAL_DEVICE_CONTROL and IRP_MJ_SCSI. This is the legacy situation. There are still old class and filter drivers out there that don’t know to set IOCTL_SCSI_EXECUTE_* and there are probably monolithic port drivers that don’t bother to check for it. In general if you’re in a storage stack you don’t mix internal ioctls and SCSI irps … it’s the safest policy.

Failing that you can check the OutputBufferLength to see if it’s unusually large. No I don’t have a good definition of “unusually large” but I don’t usually see 2GB+ I/O control buffers. Like most heurstics this will screw you when it’s wrong, but if you’re in the realm of guessing it’s one approach.

>and (b) to provide some indicator of which direction the SRB is
>transferring data.
>Its use isn’t particularly consistent …

With all the documentation that is quite a surprise :slight_smile:

Even with documentation it wouldn’t help that much. There are legacy drivers that don’t set this value or don’t look at this value so again … don’t mix internal IOCTL and SCSI requests.

>They come with SCSI_PASS_THROUGH/SCSI_PASS_THROUGH_DIRECT structures so as
>not to expose SRB to user-mode and so as to avoid
>validating SRBs which might come from user-mode. Besides, how is a user
>mode component going to provide a value like OriginalIrp

I guess what I would have expected here is the IO manager to do a similar
job as it does for other I/O requests. I mean, IRPs aren’t exposed to
user-mode either, but buffers are validated and IRPs created for
DeviceIoControl calls. I would expect the IO Manager to see that a
SCSI_PASS_THROUGH_* request is coming down, and to create an SRB on behalf
of the driver to keep the code paths sane and clean.

The I/O manager does for this IOCTL exactly what it does for all other I/O requests - it makes an IRP and tracks the buffers and then sends it to the drivers. The I/O manager doesn’t care what I/O control code is sent and doesn’t do anything magical as a result of it for any I/O request.

What also added to my confusion is three separate CD-ROM burning
applications all burning the same data to writable CD-R media, but all using
different I/O request paths. It makes one wonder why, thus my question.

They all come up with slightly different architectures. Some folks don’t want to write a kernel driver at all. Some want a kernel driver that does all the work because they think this is faster. Some want a driver that’s low in the stack because they don’t want another driver to interfere with them. Some like to add copy protection gunk into your system. This isn’t that different than taking any random N programs that theoretically do the same thing and analyzing how they get there.

“Peter Wieland” wrote in message
news:xxxxx@ntdev…
IRP_MJ_SCSI == IRP_MJ_INTERNAL_DEVICE_CONTROL. This is easily determined by
looking at the headers. No SCSI shouldn’t have its own IRP MJ code, and no
it shouldn’t reuse a number from an existing one. But it’s been that way
since I joined MS (and I tried to change it once … not possible without
breaking everyone doing storage) and so we all just have to live with it.
Someone decided we needed a MJ code for SCSI requests. I suspect
IRP_MJ_INTERNAL_DEVICE_CONTROL was reused to avoid the cost of an additional
PVOID per driver object (which at the time would have been an issue).

IOCTL_SCSI_EXECUTE_* is set in the stack location for an IRP_MJ_SCSI to (a)
allow someone handling IRP_MJ_INTERNAL_DEVICE_CONTROL to differentiate
between the two and (b) to provide some indicator of which direction the SRB
is transferring data. Its use isn’t particularly consistent … I think of
it as more of a debugging aid but I see that some of our drivers (like the
RAMDISK driver) use it to decide if the SRB in question is a read/write type
command or one of those strange SCSI commands like REQUEST_SENSE which
require more complex emulation. I think using the CDB code would have been
a much better idea.

IRP_MJ_SCSI comes with an SRB.

IOCTL_SCSI_PASS_THROUGH and IOCTL_SCSI_PASS_THROUGH_DIRECT are to send SCSI
requests from user-mode. They come with
SCSI_PASS_THROUGH/SCSI_PASS_THROUGH_DIRECT structures so as not to expose
SRB to user-mode and so as to avoid validating SRBs which might come from
user-mode. Besides, how is a user mode component going to provide a value
like OriginalIrp. IOCTL_SCSI_PASS_THROUGH is a buffered operation, while
IOCTL_SCSI_PASS_THROUGH_DIRECT direct maps the data transfer. They’re
separate control codes because they are - I suppose a flag in the
PASS_THROUGH structure could have contained the transfer mode … would that
make you happier?

So there are two ways to send a SCSI request. One for kernel-mode
components (IRP_MJ_SCSI) and one for user-mode components
(IOCTL_SCSI_PASS_THROUGH[_DIRECT]). If you want to convert a pass-through
command to a IRP_MJ_SCSI command it’s pretty straight-forward to make an SRB
and send it down. I bet you could even do it without “duplicat[ing] code
all over” if you tried. This is how the SCSI port drivers deal with it -
validate the parameters, build an SRB and then push that in through the code
that handles SRBs.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Friday, January 25, 2008 3:13 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Disk accesses

Can someone explain why there are so many different ways to send the same
SCSI request to a disk?? IRP_MJ_SCSI w/ no or some undocumented IOCT codes,
or IRP_MJ_INTERNAL_DEVICE_CONTROL (or is that actually IRP_MJ_SCSI again??)
w/: IOCTL_SCSI_EXECUTE_IN, IOCTL_SCSI_PASS_THROUGH, or
IOCTL_SCSI_PASS_THROUGH_DIRECT.

Oh, and you may get a SCSI_REQUEST_BLOCK or no wait is that a
SCSI_PASS_THROUGH_DIRECT structure? I know let’s not make them overlap so
everyone can just duplicate code all over.

I know I am probably late to the game on this…but is there a rhyme or
reason to this lovely architecture? Did I miss some documentation
somewhere?

I would love to know the why of all of this.

Bill M.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

18

redbook is the coloquial name of the standard for reading audio data for CD’s. There are old, old CDROM I/O controls to play audio (the ones which used to start the drive playing data through the drive’s audio jack) and redbook responds to those by reading audio data from the disk and feeding it out through KS.

As to “secure” - ISO9660 doesn’t define (or CDFS doesn’t expose … I’m guessing the former) any file security, so reading audio tracks off of it doesn’t seem like a real EOP to me.

-p

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Saturday, January 26, 2008 1:22 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Disk accesses

One other confusion here is I see IOCTL_SCSI_PASS_THROUGH_DIRECT requests coming from the redbook driver. How is that happening? Is there an interface for reading and writing data to media through this driver? Is this documented? Is that secure?

Bill M.
“Peter Wieland” > wrote in message news:xxxxx@ntdev…
Miniport IOCTLs are one per time at the HBA level, but I don’t think passthrough requests are. The class driver may reject pass-through requests (in particular they used to block 3rd party copy commands). And IIRC I think pass-through commands are sent untagged - perhaps that’s the “mistreating” you’re thinking of?

-p

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Friday, January 25, 2008 7:14 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Disk accesses

It is certainly an interesting architecture :slight_smile: Evolved is the most generous thing one can say about it.

IOCTL_SCSI_EXECUTE_IN: beats me - as we learned earlier some sort of cdromish thing. I only do disks.
IRP_MJ_SCSI aka IRP_MJ_INTERNAL_DEVICE_CONTROL: how class level devices talk to port level scsi devices. Cannot be sent from user mode, other kernel components can cheat. There are some differences in how scsiport handles these requests compared to IOCTL_SCSI_PASS_THROUGH, or IOCTL_SCSI_PASS_THROUGH_DIRECT which are the two methods supplied for user mode to send SRBs to scsiport directly, one using buffered io the other using an mdl. Offhand I cannot remember exactly how scsiport mistreats pass through requests compared to IRP_MJ_SCSI, but it does. I think perhaps only one at a time per hba is permitted to be in flight on the hba. I could be wrong.

Oh now you want documentation?

On Jan 25, 2008 6:12 PM, Bill McKenzie > wrote:
Can someone explain why there are so many different ways to send the same
SCSI request to a disk?? IRP_MJ_SCSI w/ no or some undocumented IOCT codes,
or IRP_MJ_INTERNAL_DEVICE_CONTROL (or is that actually IRP_MJ_SCSI again??)
w/: IOCTL_SCSI_EXECUTE_IN, IOCTL_SCSI_PASS_THROUGH, or
IOCTL_SCSI_PASS_THROUGH_DIRECT.

Oh, and you may get a SCSI_REQUEST_BLOCK or no wait is that a
SCSI_PASS_THROUGH_DIRECT structure? I know let’s not make them overlap so
everyone can just duplicate code all over.

I know I am probably late to the game on this…but is there a rhyme or
reason to this lovely architecture? Did I miss some documentation
somewhere?

I would love to know the why of all of this.

Bill M.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

–
Mark Roddy — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

19

>There are still old class and filter drivers out there that don’t know to

set IOCTL_SCSI_EXECUTE_* and there are probably monolithic port drivers
that don’t bother to check for it.

No offense honestly, but how would anyone developing one of these driver
possibly know what is correct or not?

In general if you’re in a storage stack you don’t mix internal ioctls and
SCSI irps … it’s the safest policy.

Well, I am just filtering requests at this point…not my call…but if it
were me I would definitely pick a winner and stick with it :slight_smile:

Failing that you can check the OutputBufferLength to see if it’s unusually
large. No I don’t have a good definition of “unusually large” but I don’t
usually see 2GB+ I/O control buffers. Like most heurstics this will screw
you when it’s wrong, but if you’re in the realm of guessing it’s one
approach.

That is funny, I am actually doing exactly this in my hacked up filter right
now.

Even with documentation it wouldn’t help that much. There are legacy
drivers that don’t set this value or don’t look at this value so again …
don’t mix internal IOCTL and SCSI requests.

Without documentation there will always be legacy drivers that do the wrong
thing. In fact, how can anyone be said to be doing something wrong when
there are no documented rules?

They all come up with slightly different architectures. Some folks don’t
want to write a kernel driver at all. Some want a kernel driver that does
all the work because they think this is faster. Some want a driver that’s
low in the stack because they don’t want another driver to interfere with
them. Some like to add copy protection gunk into your system. This isn’t
that different than taking any random N programs that theoretically do the
same thing and analyzing how they get there.

Right but what bothers me is when I see three separate filters in the same
place in the stack and I receive the same type of SCSI requests in three
separate ways. Some of this is due to what you say no doubt, but I suspect
some of it is “hey I sent this SCSI request this way and it worked. As it
isn’t documented lets just do what works” and different groups found
different answers to this problem.

Not my problem ultimately, I can certainly work around all of this…but it
seems a problem you guys might not want.

Bill M.