Re: [PATCH] sbp2: better check of transfer direction (protects from panic or oops)

Re: [PATCH] sbp2: better check of transfer direction (protects from panic or oops)

[Stefan Richter]

(Adding linux-scsi@vger.kernel.org again since there are more question 
marks than I thought...)

Jody McIntyre wrote:
> On Thu, Dec 08, 2005 at 10:42:02PM +0100, Stefan Richter wrote:
> 
>>sbp2: better check of transfer direction (protects from panic or oops)
>>
>>Move transfer direction check in sbp2_create_command_orb() up a bit to catch
>>more error cases.  Now we log an error note and proceed happily instead of a
>>kernel panic or oops.  Debugging and original variant of the patch by Andrew
>>de Quincey.
> 
> 
> Do you still want this if Jens' patch is applied to the SCSI subsystem?
> Extra checks are nice, but extra code is not :)  It's up to you...
> 
> Cheers,
> Jody

scsi_prep_fn() is not the only path which may set the transfer 
direction. Unless *all* paths are guaranteed to send us a proper 
direction, we still need the patch for sbp2_create_command_orb().

If all *known* paths are fixed, we could consider to override a bad 
transfer direction silently like e.g. usb_storage does. But we should 
not leave sbp2_create_command_orb() as fragile as it currently is.

I wonder if I know all paths where the direction could be set.

I also wonder if there could ever be something else execpt DMA_NONE, 
DMA_TO_DEVICE, or DMA_FROM_DEVICE being passed to sbp2. If it is 
guaranteed that scsi_cmnd.sc_data_direction is one of these three, we 
should remove ieee1394/sbp2.h::sbp2scsi_direction_table[].

> 
> 
> 
>>Problem became apparent when iPods were to be ejected:
>>http://marc.theaimsgroup.com/?l=linux1394-devel&m=113399994920181
>>http://marc.theaimsgroup.com/?l=linux1394-user&m=112152701817435
>>
>>Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
>>Cc: Ben Collins <bcollins@debian.org>
>>Cc: Andrew de Quincey <adq@lidskialf.net>
>>
>>---
>> drivers/ieee1394/sbp2.c |   24 ++++++++++++++----------
>> 1 files changed, 14 insertions(+), 10 deletions(-)
>>
>>--- linux/drivers/ieee1394.orig/sbp2.c	2005-11-24 23:10:21.000000000 +0100
>>+++ linux/drivers/ieee1394/sbp2.c	2005-12-08 22:06:49.000000000 +0100
>>@@ -1785,6 +1785,20 @@ static int sbp2_create_command_orb(struc
>> 	}
>> 
>> 	/*
>>+	 * Sanity check, in case we got a bogus direction from upper layers
>>+	 * or if sbp2scsi_direction_table is inadequate.
>>+	 */
>>+	if (orb_direction != ORB_DIRECTION_NO_DATA_TRANSFER &&
>>+	    scsi_request_bufflen == 0) {
>>+		SBP2_ERR("Transfer direction is \"%s\" but request buffer "
>>+			 "length is 0. This is a bug! Enforcing transfer "
>>+			 "direction DMA_NONE",
>>+			 orb_direction == ORB_DIRECTION_WRITE_TO_MEDIA ?
>>+			 "out" : "in");
>>+		orb_direction = ORB_DIRECTION_NO_DATA_TRANSFER;
>>+	}
>>+
>>+	/*
>> 	 * Set-up our pagetable stuff... unfortunately, this has become
>> 	 * messier than I'd like. Need to clean this up a bit.   ;-)
>> 	 */
>>@@ -1900,16 +1914,6 @@ static int sbp2_create_command_orb(struc
>> 			command_orb->misc |= ORB_SET_DATA_SIZE(scsi_request_bufflen);
>> 			command_orb->misc |= ORB_SET_DIRECTION(orb_direction);
>> 
>>-			/*
>>-			 * Sanity, in case our direction table is not
>>-			 * up-to-date
>>-			 */
>>-			if (!scsi_request_bufflen) {
>>-				command_orb->data_descriptor_hi = 0x0;
>>-				command_orb->data_descriptor_lo = 0x0;
>>-				command_orb->misc |= ORB_SET_DIRECTION(1);
>>-			}
>>-
>> 		} else {
>> 			/*
>> 			 * Need to turn this into page tables, since the
>>


-- 
Stefan Richter
-=====-=-=-= ==-- -=--=
http://arcgraph.de/sr/


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [PATCH] sbp2: better check of transfer direction (protects from panic or oops)

[Jody McIntyre]

On Fri, Dec 09, 2005 at 08:01:11PM +0100, Stefan Richter wrote:

> scsi_prep_fn() is not the only path which may set the transfer 
> direction. Unless *all* paths are guaranteed to send us a proper 
> direction, we still need the patch for sbp2_create_command_orb().

I realize that.. The question is "should we rely on the SCSI subsystem
to set a valid direction, or should we be checking it ourselves?"

> If all *known* paths are fixed, we could consider to override a bad 
> transfer direction silently like e.g. usb_storage does. But we should 
> not leave sbp2_create_command_orb() as fragile as it currently is.

I didn't know USB did this.. the fact that USB checks itself suggests
that we also need a check, and if we're checking we may as well warn.

Cheers,
Jody

> I wonder if I know all paths where the direction could be set.
> 
> I also wonder if there could ever be something else execpt DMA_NONE, 
> DMA_TO_DEVICE, or DMA_FROM_DEVICE being passed to sbp2. If it is 
> guaranteed that scsi_cmnd.sc_data_direction is one of these three, we 
> should remove ieee1394/sbp2.h::sbp2scsi_direction_table[].
> 
> >
> >
> >
> >>Problem became apparent when iPods were to be ejected:
> >>http://marc.theaimsgroup.com/?l=linux1394-devel&m=113399994920181
> >>http://marc.theaimsgroup.com/?l=linux1394-user&m=112152701817435
> >>
> >>Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
> >>Cc: Ben Collins <bcollins@debian.org>
> >>Cc: Andrew de Quincey <adq@lidskialf.net>
> >>
> >>---
> >>drivers/ieee1394/sbp2.c |   24 ++++++++++++++----------
> >>1 files changed, 14 insertions(+), 10 deletions(-)
> >>
> >>--- linux/drivers/ieee1394.orig/sbp2.c	2005-11-24 
> >>23:10:21.000000000 +0100
> >>+++ linux/drivers/ieee1394/sbp2.c	2005-12-08 22:06:49.000000000 +0100
> >>@@ -1785,6 +1785,20 @@ static int sbp2_create_command_orb(struc
> >>	}
> >>
> >>	/*
> >>+	 * Sanity check, in case we got a bogus direction from upper layers
> >>+	 * or if sbp2scsi_direction_table is inadequate.
> >>+	 */
> >>+	if (orb_direction != ORB_DIRECTION_NO_DATA_TRANSFER &&
> >>+	    scsi_request_bufflen == 0) {
> >>+		SBP2_ERR("Transfer direction is \"%s\" but request buffer "
> >>+			 "length is 0. This is a bug! Enforcing transfer "
> >>+			 "direction DMA_NONE",
> >>+			 orb_direction == ORB_DIRECTION_WRITE_TO_MEDIA ?
> >>+			 "out" : "in");
> >>+		orb_direction = ORB_DIRECTION_NO_DATA_TRANSFER;
> >>+	}
> >>+
> >>+	/*
> >>	 * Set-up our pagetable stuff... unfortunately, this has become
> >>	 * messier than I'd like. Need to clean this up a bit.   ;-)
> >>	 */
> >>@@ -1900,16 +1914,6 @@ static int sbp2_create_command_orb(struc
> >>			command_orb->misc |= 
> >>			ORB_SET_DATA_SIZE(scsi_request_bufflen);
> >>			command_orb->misc |= 
> >>			ORB_SET_DIRECTION(orb_direction);
> >>
> >>-			/*
> >>-			 * Sanity, in case our direction table is not
> >>-			 * up-to-date
> >>-			 */
> >>-			if (!scsi_request_bufflen) {
> >>-				command_orb->data_descriptor_hi = 0x0;
> >>-				command_orb->data_descriptor_lo = 0x0;
> >>-				command_orb->misc |= ORB_SET_DIRECTION(1);
> >>-			}
> >>-
> >>		} else {
> >>			/*
> >>			 * Need to turn this into page tables, since the
> >>
> 
> 
> -- 
> Stefan Richter
> -=====-=-=-= ==-- -=--=
> http://arcgraph.de/sr/

-- 


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [PATCH] sbp2: better check of transfer direction (protects from panic or oops)

[Stefan Richter]

Jody McIntyre wrote:
> On Fri, Dec 09, 2005 at 08:01:11PM +0100, Stefan Richter wrote:
>>If all *known* paths are fixed, we could consider to override a bad 
>>transfer direction silently like e.g. usb_storage does. But we should 
>>not leave sbp2_create_command_orb() as fragile as it currently is.
> 
> I didn't know USB did this.. the fact that USB checks itself suggests
> that we also need a check, and if we're checking we may as well warn.

Well, usb_storage actually does not override it explicitly. It just acts 
only on DMA_FROM_DEVICE or DMA_TO_DEVICE after having first checked for 
transfer buffer length AFAIU. However this is just one example. It 
differs between SCSI low level drivers. I don't know if any of them logs 
warnings about suspect transfer directions.
-- 
Stefan Richter
-=====-=-=-= ==-- -=--=
http://arcgraph.de/sr/

Re: [PATCH] sbp2: better check of transfer direction (protects from panic or oops)

[James Bottomley]

On Fri, 2005-12-09 at 14:34 -0500, Jody McIntyre wrote:
> I realize that.. The question is "should we rely on the SCSI subsystem
> to set a valid direction, or should we be checking it ourselves?"

You should rely on the SCSI subsystem.  If everyone has their own work
around, a) we get bloated drivers and b) the original bug is never
fixed.

James




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [PATCH] sbp2: better check of transfer direction (protects from panic or oops)

[Stefan Richter]

I wrote on 2005-12-09:
> Jody McIntyre wrote:
...
>> Do you still want this if Jens' patch is applied to the SCSI subsystem?
>> Extra checks are nice, but extra code is not :)  It's up to you...
...
> scsi_prep_fn() is not the only path which may set the transfer 
> direction. Unless *all* paths are guaranteed to send us a proper 
> direction, we still need the patch for sbp2_create_command_orb().
> 
> If all *known* paths are fixed, we could consider to override a bad 
> transfer direction silently like e.g. usb_storage does. But we should 
> not leave sbp2_create_command_orb() as fragile as it currently is.
> 
> I wonder if I know all paths where the direction could be set.

I learned now of many more points which set the transfer direction. It 
can apparently even come from userspace.

> I also wonder if there could ever be something else execpt DMA_NONE, 
> DMA_TO_DEVICE, or DMA_FROM_DEVICE being passed to sbp2. If it is 
> guaranteed that scsi_cmnd.sc_data_direction is one of these three, we 
> should remove ieee1394/sbp2.h::sbp2scsi_direction_table[].

AFAIU it is still possibly that DMA_BIDIRECTIONAL is passed down. 
However I think now that we should delete sbp2scsi_direction_table 
anyway and simply reject DMA_BIDIRECTIONAL. This is what a few other 
SCSI low-level drivers do, and I think it is appropriate for a low-level 
driver to fail such commands instead of converting them to a "known" 
direction.

Or am I missing something?
-- 
Stefan Richter
-=====-=-=-= ==-- -=-=-
http://arcgraph.de/sr/


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [PATCH] sbp2: better check of transfer direction (protects from panic or oops)

[Christoph Hellwig]

On Sat, Dec 10, 2005 at 03:05:41PM +0100, Stefan Richter wrote:
> I learned now of many more points which set the transfer direction. It 
> can apparently even come from userspace.

It can be specified with sg.

> >I also wonder if there could ever be something else execpt DMA_NONE, 
> >DMA_TO_DEVICE, or DMA_FROM_DEVICE being passed to sbp2. If it is 
> >guaranteed that scsi_cmnd.sc_data_direction is one of these three, we 
> >should remove ieee1394/sbp2.h::sbp2scsi_direction_table[].
> 
> AFAIU it is still possibly that DMA_BIDIRECTIONAL is passed down. 
> However I think now that we should delete sbp2scsi_direction_table 
> anyway and simply reject DMA_BIDIRECTIONAL. This is what a few other 
> SCSI low-level drivers do, and I think it is appropriate for a low-level 
> driver to fail such commands instead of converting them to a "known" 
> direction.

Yes, please.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [PATCH] sbp2: better check of transfer direction (protects from panic or oops)

[Douglas Gilbert]

Stefan Richter wrote:
> I wrote on 2005-12-09:
> 
>> Jody McIntyre wrote:
> 
> ...
> 
>>> Do you still want this if Jens' patch is applied to the SCSI subsystem?
>>> Extra checks are nice, but extra code is not :)  It's up to you...
> 
> ...
> 
>> scsi_prep_fn() is not the only path which may set the transfer
>> direction. Unless *all* paths are guaranteed to send us a proper
>> direction, we still need the patch for sbp2_create_command_orb().
>>
>> If all *known* paths are fixed, we could consider to override a bad
>> transfer direction silently like e.g. usb_storage does. But we should
>> not leave sbp2_create_command_orb() as fragile as it currently is.
>>
>> I wonder if I know all paths where the direction could be set.
> 
> 
> I learned now of many more points which set the transfer direction. It
> can apparently even come from userspace.
> 
>> I also wonder if there could ever be something else execpt DMA_NONE,
>> DMA_TO_DEVICE, or DMA_FROM_DEVICE being passed to sbp2. If it is
>> guaranteed that scsi_cmnd.sc_data_direction is one of these three, we
>> should remove ieee1394/sbp2.h::sbp2scsi_direction_table[].
> 
> 
> AFAIU it is still possibly that DMA_BIDIRECTIONAL is passed down.
> However I think now that we should delete sbp2scsi_direction_table
> anyway and simply reject DMA_BIDIRECTIONAL. This is what a few other
> SCSI low-level drivers do, and I think it is appropriate for a low-level
> driver to fail such commands instead of converting them to a "known"
> direction.
> 
> Or am I missing something?

SCSI does define various bidirectional commands, mostly
in OSD (Object Storage) and a couple in SBC (for disks,
RAID related). Linux does support not them yet.

About the time when Linux supports command lengths
greater than 16 bytes, it will also need to support
bidirectional data transfers. Perhaps bidirectional
data transfers would be implemented by two scatter
gather lists.

Doug Gilbert


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [PATCH] sbp2: better check of transfer direction (protects from panic or oops)

[Christoph Hellwig]

On Sun, Dec 11, 2005 at 07:46:52AM +1000, Douglas Gilbert wrote:
> SCSI does define various bidirectional commands, mostly
> in OSD (Object Storage) and a couple in SBC (for disks,
> RAID related). Linux does support not them yet.
> 
> About the time when Linux supports command lengths
> greater than 16 bytes, it will also need to support
> bidirectional data transfers. Perhaps bidirectional
> data transfers would be implemented by two scatter
> gather lists.

Yes.  but we can't just allow them for existing LLDDs because that would
open a _huge_ can of worms.  We'll need a flag similar to how we handle
e.g. 16 byte cdb support.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click