From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3003521EB5283 for ; Thu, 31 Aug 2017 06:46:46 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 339A95AFD9; Thu, 31 Aug 2017 13:49:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 339A95AFD9 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-89.phx2.redhat.com [10.3.116.89]) by smtp.corp.redhat.com (Postfix) with ESMTP id EE04C92D0C; Thu, 31 Aug 2017 13:49:27 +0000 (UTC) From: Laszlo Ersek To: Brijesh Singh , edk2-devel@lists.01.org Cc: Jordan Justen , Tom Lendacky , Ard Biesheuvel References: <1504125903-29816-1-git-send-email-brijesh.singh@amd.com> <1504125903-29816-4-git-send-email-brijesh.singh@amd.com> <3e3e8174-616d-8f34-7682-02f6e492fb24@redhat.com> Message-ID: <885cf87f-eab8-a429-cf40-eb6905d8378e@redhat.com> Date: Thu, 31 Aug 2017 15:49:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <3e3e8174-616d-8f34-7682-02f6e492fb24@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 31 Aug 2017 13:49:29 +0000 (UTC) Subject: Re: [PATCH v2 3/4] Ovmfpkg/VirtioScsiDxe: map virtio-scsi request and response buffers X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 13:46:46 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 08/31/17 15:23, Laszlo Ersek wrote: > On 08/30/17 22:45, Brijesh Singh wrote: >> @@ -492,10 +645,50 @@ VirtioScsiPassThru ( >> // >> if (VirtioFlush (Dev->VirtIo, VIRTIO_SCSI_REQUEST_QUEUE, &Dev->Ring, >> &Indices, NULL) != EFI_SUCCESS) { >> - return ReportHostAdapterError (Packet); >> + Status = ReportHostAdapterError (Packet); >> + goto UnmapResponseBuffer; >> } >> >> - return ParseResponse (Packet, &Response); >> + Status = ParseResponse (Packet, Response); >> + >> + // >> + // If virtio request was successful and it was a CPU read request then we >> + // have used an intermediate buffer. Copy the data from intermediate buffer >> + // to the final buffer. >> + // >> + if (!EFI_ERROR (Status) && (Packet->InTransferLength > 0)) { >> + CopyMem (Packet->InDataBuffer, InDataBuffer, Packet->InTransferLength); >> + } > > (7) The comment is exactly right, but the condition that you check > after is incorrect. > > The right thing to do is to call CopyMem() *unconditionally*. > > Namely, at this point we are past ParseResponse(). As I wrote before, > ParseResponse() updates the Packet->... fields in every case, even if > it reports an EFI_STATUS that is different from EFI_SUCCESS. And > whatever we expose to the caller through "Packet->InTransferLength" > *must* be reflected in "Packet->InDataBuffer" regardless of return > status. > > Therefore the Status check must be dropped. And then we need not check > (Packet->InTransferLength>0) either, because the CopyMem() will deal > with it internally. > > Think of it like this: the "worst" that can happen, on error, is that > "Packet->InTransferLength" is unchanged from its "input" value, and we > overwrite the caller's "Packet->InDataBuffer" entirely. What is the > data we are going to put there? It's all zeroes, from your > > ZeroMem (InDataBuffer, Packet->InTransferLength); > > higher up. > > So, again, this CopyMem() needs to be unconditional -- as the comment > says, if the *virtio* request was successful (== we talked to the > virtio-scsi adapter), then we have to copy the data, even if the > *SCSI* request produced an error status in ParseResponse. I have to correct myself a little bit -- although I think you would have caught me anyway :) --, namely we should keep the "if", but the condition should be: InDataBuffer != NULL Admittedly, it is likely that none of the CopyMem() implementations would have problems with a NULL "SourceBuffer", if "Length" was zero. Nonetheless, the interface contract in MdePkg/Include/Library/BaseMemoryLib.h does not mark SourceBuffer OPTIONAL -- neither does the UEFI spec, for the similar gBS->CopyMem() boot service --, for the case when Length==0, so we should do an explicit check: if (InDataBuffer != NULL) { CopyMem (Packet->InDataBuffer, InDataBuffer, Packet->InTransferLength); } Thank you, Laszlo