Re: [Qemu-devel] [PATCH] Fix ATAPI GET_CONFIGURATION function

[Alexander Graf]

On May 25, 2008, at 9:53 AM, Carlo Marcelo Arenas Belon wrote:

> On Sat, May 24, 2008 at 12:31:01PM +0200, Alexander Graf wrote:
> > Is there anything particularly wrong with this patch?
>
> no, but the SPEC (I used MMC6 r01) says :
>
> 6.5.1.4 Allocation Length
>
> The Allocation Length field specifies the maximum length in bytes of  
> the Get
> Configuration response data.  An Allocation Length field of zero  
> indicates
> that no data shall be transferred.  This condition shall not be  
> considered an
> error.

This means that the Allocation Length field in the request specifies  
the maximum bytes of data to be returned. This does not affect the  
"Data Length" field in the response, which indicates the maximum  
amount of data available.

> this is only implicitly supported by truncating the response using  
> max_len
> for the ide_atapi_cmd_reply with your patch and so the work of  
> generating the
> response is still happening regardless.

Isn't io_buffer memcpy()ed by at most max_len in the end to the DMA  
buffer of the target? Bytes after max_len should not even be written  
to target OS memory.

> > Does it break any guest OSs I am not aware of?
>
> the original implementation (*) broke [Open]Solaris by overflowing  
> the buffer
> that was used in the calls to detect the CDROM/DVDROM (using a 8  
> byte buffer)

I don't see how that could break anything. The normal way of receiving  
a dynamic length packet with SCSI is as follows:

- Send a request with an Allocation Length of 4 (or slightly more) bytes
- Receive the response header, which includes the "Data Length" field.  
Now the OS knows the full length of the response packet
- Send a request with an Allocation Length of "Data Length" bytes
- Receive the full packet

I am pretty sure Solaris does the same. If anything breaks, it's a bug  
in the implementation of how buf gets written into the client memory.

Furthermore I tried to issue the same command on a real DVD Drive.  
There is a handy tool in Linux called "sg_raw". Using that you can  
just issue raw SCSI commands to your device. I received the following  
results:

 # sg_raw -vv -r 0x00 /dev/sg1 46 00 00 00 00 00 00 00 00 00
open /dev/sg1 with flags=0x802
SCSI Status: Good

Sense Information:
sense buffer empty

No data received

# sg_raw -vv -r 0x04 /dev/sg1 46 00 00 00 00 00 00 00 04 00
open /dev/sg1 with flags=0x802
SCSI Status: Good

Sense Information:
sense buffer empty

Received 4 bytes of data:
 00     00 00 00 88                                         ....

# sg_raw -vv -r 0x08 /dev/sg1 46 00 00 00 00 00 00 00 08 00
open /dev/sg1 with flags=0x802
SCSI Status: Good

Sense Information:
sense buffer empty

Received 8 bytes of data:
 00     00 00 00 88 00 00 00 10                             ........

# sg_raw -vv -r 0x88 /dev/sg1 46 00 00 00 00 00 00 00 88 00
open /dev/sg1 with flags=0x802
SCSI Status: Good

Sense Information:
sense buffer empty

Received 136 bytes of data:
 00     00 00 00 88 00 00 00 10  00 00 03 08 00 10 01  
00    ................
 10     00 08 00 00 00 01 03 04  00 00 00 02 00 02 03  
04    ................
 20     00 00 00 00 00 03 03 04  29 00 00 00 00 10 01  
08    ........).......
 30     00 00 08 00 00 10 01 00  00 1d 00 00 00 1e 04  
04    ................
 40     03 00 00 00 00 1f 01 00  00 2a 00 04 00 01 00  
00    .........*......
 50     00 2b 00 04 00 00 00 00  00 3b 01 04 00 00 00 00    . 
+.......;......
 60     01 00 03 00 01 03 00 04  03 00 01 00 01 04 03  
00    ................
 70     01 05 03 00 01 06 04 04  00 00 00 01 01 07 0d  
04    ................
 80     0c 00 00 00 01 0b 04 04                             ........


As you can see the "Data Length" field in the response is constantly  
the maximum bytes available as response.

Alex

> Carlo
>
> (*) http://svn.savannah.gnu.org/viewvc/trunk/hw/ide.c?root=qemu&r1=3147&r2=3161