From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35842) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpOPY-0005uV-AV for qemu-devel@nongnu.org; Mon, 23 Jan 2012 13:14:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpOPU-000152-5D for qemu-devel@nongnu.org; Mon, 23 Jan 2012 13:14:32 -0500 Date: Mon, 23 Jan 2012 13:14:26 -0500 From: Thomas Higdon Message-ID: <20120123181426.GA14494@akamai.com> References: <20120123171525.GM32632@akamai.com> <4F1D9D4A.3000104@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F1D9D4A.3000104@redhat.com> Subject: Re: [Qemu-devel] [PATCH] scsi: restrict buffer length to req->cmd.xfer for responses to INQUIRY commands. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-trivial , Kevin Wolf , qemu-devel , Paul Brook On Mon, Jan 23, 2012 at 12:47:54PM -0500, Paolo Bonzini wrote: > On 01/23/2012 06:15 PM, Thomas Higdon wrote: > > This prevents the emulated SCSI device from trying to DMA more bytes to the > > initiator than are expected. Without this, the SCRIPTS code in the emulated LSI > > device eventually raises a DMA interrupt for a data overrun when an INQUIRY > > command whose buflen exceeds req->cmd.xfer is processed. It's the > > responsibility of the client to provide a request buffer and allocation > > length that are large enough for the result of the command. > > > > I'm no expert on SCSI (or qemu), but this appears to be more correct behavior > > than before, and makes my SCSI INQUIRY commands more successful. > > Yes, this is correct. SCSI says "The device server shall terminate > transfers to the Data-In Buffer when the number of bytes or blocks > specified by the ALLOCATION LENGTH field have been transferred or when > all available data have been transferred, whichever is less". > > The same is already done for example for MODE SENSE commands. > > Can you please also do the same REPORT LUNS and INQUIRY in hw/scsi-bus.c? You're talking about the scsi_target_emulate_report_luns() and scsi_target_emulate_inquiry() functions in hw/scsi-bus.c? By my read of the code, these appear safe. In both functions, I see len getting set via calls to MIN with r->req->cmd.xfer as one of the arguments. If you're referring to something else, can you be more specific?