From nobody Mon Apr 29 19:57:17 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) client-ip=198.145.21.10; envelope-from=edk2-devel-bounces@lists.01.org; helo=ml01.01.org; Authentication-Results: mx.zohomail.com; spf=none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) smtp.mailfrom=edk2-devel-bounces@lists.01.org Return-Path: Received: from ml01.01.org (ml01.01.org [198.145.21.10]) by mx.zohomail.com with SMTPS id 1503027488328505.129477941926; Thu, 17 Aug 2017 20:38:08 -0700 (PDT) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 35BCD2095B9D1; Thu, 17 Aug 2017 20:35:38 -0700 (PDT) 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 801BC21E79033 for ; Thu, 17 Aug 2017 20:35:36 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E1F39356E1; Fri, 18 Aug 2017 03:38:03 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-49.phx2.redhat.com [10.3.116.49]) by smtp.corp.redhat.com (Postfix) with ESMTP id E3AF660FB6; Fri, 18 Aug 2017 03:38:01 +0000 (UTC) X-Original-To: edk2-devel@lists.01.org DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E1F39356E1 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com From: Laszlo Ersek To: edk2-devel-01 Date: Fri, 18 Aug 2017 05:37:55 +0200 Message-Id: <20170818033757.16153-2-lersek@redhat.com> In-Reply-To: <20170818033757.16153-1-lersek@redhat.com> References: <20170818033757.16153-1-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 18 Aug 2017 03:38:04 +0000 (UTC) Subject: [edk2] [PATCH 1/3] MdeModulePkg/ScsiBusDxe: don't produce ScsiIo for nonexistent LUNs, part 1 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: , Cc: Paolo Bonzini , Feng Tian , Eric Dong , Star Zeng , Hannes Reinecke MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" X-ZohoMail: RSF_4 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" The SPC-4 spec says about the INQUIRY data, in "Table 138 -- Peripheral qualifier": > Qualifier =3D 011b The device server is not capable of supporting a > peripheral device on this logical unit. For this > peripheral qualifier the peripheral device type shall > be set to 1Fh. All other peripheral device type values > are reserved for this peripheral qualifier. Accordingly, the DiscoverScsiDevice() function returns FALSE if Peripheral_Qualifier is 3 decimal, but Peripheral_Type differs from 1Fh. This is a valid sanity check -- such combinations are reserved. When Peripheral_Qualifier is 3, and Peripheral_Type is 1Fh, then DiscoverScsiDevice() returns TRUE. While this combination is not reserved, returning TRUE for it is incorrect: Peripheral_Type 1Fh stands for "Unknown or no device type", and this combination is returned in particular when the INQUIRY command was directed to a nonexistent LUN. Quoting the spec: > In response to an INQUIRY command received by an incorrect logical unit, > the SCSI target device shall return the INQUIRY data with the peripheral > qualifier set to the value defined in 6.4.2. [...] > > [...] > > The PERIPHERAL QUALIFIER field and PERIPHERAL DEVICE TYPE field identify > the peripheral device connected to the logical unit. If the SCSI target > device is not capable of supporting a peripheral device connected to > this logical unit, the device server shall set these fields to 7Fh > (i.e., PERIPHERAL QUALIFIER field set to 011b and PERIPHERAL DEVICE TYPE > field set to 1Fh). The consequence of this bug is that for each nonexistent Target/LUN pair, we produce a useless ScsiIo protocol interface. The internal "ScsiIoDevice->ScsiDeviceType" field will be set to 0x1f, and it will be returned to higher-level SCSI drivers when they call ScsiIo->GetDeviceType(). Given that 0x1f means "Unknown or no device type", no higher-level driver can ever support it, so these ScsiIo protocol interfaces are useless. The fix is to return FALSE for the (Peripheral_Qualifier=3D3, Peripheral_Type=3D0x1f) combination. With that however we reject the whole Peripheral_Qualifier=3D3 space (justifiedly -- see the definition above), which lets us simplify the code. Cc: Eric Dong Cc: Feng Tian Cc: Hannes Reinecke Cc: Paolo Bonzini Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek Reviewed-by: Star Zeng --- MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c b/MdeModulePkg/Bus/= Scsi/ScsiBusDxe/ScsiBus.c index 0802b617268f..72e3da8967b2 100644 --- a/MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c +++ b/MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c @@ -1348,21 +1348,13 @@ DiscoverScsiDevice ( =20 // // Retrieved inquiry data successfully // - if ((InquiryData->Peripheral_Qualifier !=3D 0) && - (InquiryData->Peripheral_Qualifier !=3D 3)) { + if (InquiryData->Peripheral_Qualifier !=3D 0) { ScsiDeviceFound =3D FALSE; goto Done; } =20 - if (InquiryData->Peripheral_Qualifier =3D=3D 3) { - if (InquiryData->Peripheral_Type !=3D 0x1f) { - ScsiDeviceFound =3D FALSE; - goto Done; - } - } - if (0x1e >=3D InquiryData->Peripheral_Type && InquiryData->Peripheral_Ty= pe >=3D 0xa) { ScsiDeviceFound =3D FALSE; goto Done; } --=20 2.14.1.3.gb7cf6e02401b _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel From nobody Mon Apr 29 19:57:17 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) client-ip=198.145.21.10; envelope-from=edk2-devel-bounces@lists.01.org; helo=ml01.01.org; Authentication-Results: mx.zohomail.com; spf=none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) smtp.mailfrom=edk2-devel-bounces@lists.01.org Return-Path: Received: from ml01.01.org (ml01.01.org [198.145.21.10]) by mx.zohomail.com with SMTPS id 1503027490516877.6292355390834; Thu, 17 Aug 2017 20:38:10 -0700 (PDT) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 72F8A2095B9F5; Thu, 17 Aug 2017 20:35:40 -0700 (PDT) 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 257BE21E79033 for ; Thu, 17 Aug 2017 20:35:39 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 88F3637EEF; Fri, 18 Aug 2017 03:38:06 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-49.phx2.redhat.com [10.3.116.49]) by smtp.corp.redhat.com (Postfix) with ESMTP id EC0DB60FB6; Fri, 18 Aug 2017 03:38:04 +0000 (UTC) X-Original-To: edk2-devel@lists.01.org DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 88F3637EEF Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com From: Laszlo Ersek To: edk2-devel-01 Date: Fri, 18 Aug 2017 05:37:56 +0200 Message-Id: <20170818033757.16153-3-lersek@redhat.com> In-Reply-To: <20170818033757.16153-1-lersek@redhat.com> References: <20170818033757.16153-1-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Fri, 18 Aug 2017 03:38:06 +0000 (UTC) Subject: [edk2] [PATCH 2/3] MdeModulePkg/ScsiBusDxe: remove redundant "else" after "break" statement 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: , Cc: Paolo Bonzini , Feng Tian , Eric Dong , Star Zeng , Hannes Reinecke MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" X-ZohoMail: RSF_4 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" The code after the "if" statement is only reachable if the first branch with the "break" is not taken. Therefore we can move the "else" branch after the "if" statement, simplifying the code. Cc: Eric Dong Cc: Feng Tian Cc: Hannes Reinecke Cc: Paolo Bonzini Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek Reviewed-by: Star Zeng --- MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c b/MdeModulePkg/Bus/= Scsi/ScsiBusDxe/ScsiBus.c index 72e3da8967b2..1068770cd87f 100644 --- a/MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c +++ b/MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c @@ -1332,11 +1332,12 @@ DiscoverScsiDevice ( FALSE ); if (!EFI_ERROR (Status)) { break; - } else if ((Status =3D=3D EFI_BAD_BUFFER_SIZE) ||=20 - (Status =3D=3D EFI_INVALID_PARAMETER) || - (Status =3D=3D EFI_UNSUPPORTED)) { + } + if ((Status =3D=3D EFI_BAD_BUFFER_SIZE) || + (Status =3D=3D EFI_INVALID_PARAMETER) || + (Status =3D=3D EFI_UNSUPPORTED)) { ScsiDeviceFound =3D FALSE; goto Done; } } --=20 2.14.1.3.gb7cf6e02401b _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel From nobody Mon Apr 29 19:57:17 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) client-ip=198.145.21.10; envelope-from=edk2-devel-bounces@lists.01.org; helo=ml01.01.org; Authentication-Results: mx.zohomail.com; spf=none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) smtp.mailfrom=edk2-devel-bounces@lists.01.org Return-Path: Received: from ml01.01.org (ml01.01.org [198.145.21.10]) by mx.zohomail.com with SMTPS id 1503027493288293.3886545269643; Thu, 17 Aug 2017 20:38:13 -0700 (PDT) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id BAB8D2095B9FE; Thu, 17 Aug 2017 20:35:43 -0700 (PDT) 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 00C9021E79033 for ; Thu, 17 Aug 2017 20:35:41 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6172E81DE8; Fri, 18 Aug 2017 03:38:08 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-49.phx2.redhat.com [10.3.116.49]) by smtp.corp.redhat.com (Postfix) with ESMTP id DC5C660247; Fri, 18 Aug 2017 03:38:06 +0000 (UTC) X-Original-To: edk2-devel@lists.01.org DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6172E81DE8 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com From: Laszlo Ersek To: edk2-devel-01 Date: Fri, 18 Aug 2017 05:37:57 +0200 Message-Id: <20170818033757.16153-4-lersek@redhat.com> In-Reply-To: <20170818033757.16153-1-lersek@redhat.com> References: <20170818033757.16153-1-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Fri, 18 Aug 2017 03:38:08 +0000 (UTC) Subject: [edk2] [PATCH 3/3] MdeModulePkg/ScsiBusDxe: don't produce ScsiIo for nonexistent LUNs, part 2 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: , Cc: Paolo Bonzini , Feng Tian , Eric Dong , Star Zeng , Hannes Reinecke MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" X-ZohoMail: RSF_4 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" The SPC-4 says about INQUIRY, > In response to an INQUIRY command received by an incorrect logical unit, > the SCSI target device shall return the INQUIRY data with the peripheral > qualifier set to the value defined in 6.4.2. The INQUIRY command shall > return CHECK CONDITION status only when the device server is unable to > return the requested INQUIRY data. When a device server takes the second branch, and returns CHECK CONDITION for a nonexistent LUN, the InquiryData structure in the DiscoverScsiDevice() function remains filled with the original zeros. DiscoverScsiDevice() then sees zero in both Peripheral_Qualifier and Peripheral_Type, and therefore ScsiBusDxe produces a ScsiIo protocol instance with device type zero, for the nonexistent LUN. Device type zero is EFI_SCSI_TYPE_DISK. Thus ScsiDiskDxe binds the bogus ScsiIo protocol interface, and produces a similarly bogus BlockIo interface on top. This ripples up to BDS, where UefiBootManagerLib can auto-generate bogus UEFI boot options for the nonexistent LUNs. This has been encountered with QEMU, after commit ded6ddc5a7b9 ("scsi: clarify sense codes for LUN0 emulation", 2017-08-04). QEMU now answers INQUIRY commands that were directed to nonexistent LUNs with: > DiscoverScsiDevice:1361: Lun=3D2 HostAdapterStatus=3D0 TargetStatus=3D2 > SenseDataLength=3D18 InquiryDataLength=3D96 > Sense { > Sense 000000 70 00 05 00 00 00 00 0A 00 00 00 00 25 00 00 00 > Sense 000010 00 00 > Sense } > Inquiry { > Inquiry 000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Inquiry 000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Inquiry 000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Inquiry 000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Inquiry 000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Inquiry 000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Inquiry } The interesting fields are: - HostAdapterStatus=3D0 (OK), - TargetStatus=3D2 (CHECK CONDITION), - Sense/Error_Code=3D0x70 (Current error, Fixed description) - Sense/Sense_Key=3D0x05 (ILLEGAL REQUEST) According to SPC-4 "Table 41 -- Sense key descriptions (part 2 of 2)", ILLEGAL REQUEST is justified when "the command was addressed to an incorrect logical unit number". Thus, recognize this kind of answer for nonexistent LUNs. ( Checking the status fields and the sense data is justified anyway, according to the documentation of ScsiInquiryCommand(): > @retval EFI_SUCCESS The command was executed > successfully. See > HostAdapterStatus, > TargetStatus, SenseDataLength, > and SenseData in that order for > additional status information. ) Cc: Eric Dong Cc: Feng Tian Cc: Hannes Reinecke Cc: Paolo Bonzini Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek Reviewed-by: Star Zeng --- MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c | 24 ++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c b/MdeModulePkg/Bus/= Scsi/ScsiBusDxe/ScsiBus.c index 1068770cd87f..21034aab19f7 100644 --- a/MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c +++ b/MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c @@ -1297,42 +1297,61 @@ DiscoverScsiDevice ( UINT8 SenseDataLength; UINT8 HostAdapterStatus; UINT8 TargetStatus; EFI_SCSI_INQUIRY_DATA *InquiryData; + EFI_SCSI_SENSE_DATA *SenseData; UINT8 MaxRetry; UINT8 Index; BOOLEAN ScsiDeviceFound; =20 HostAdapterStatus =3D 0; TargetStatus =3D 0; + SenseData =3D NULL; =20 InquiryData =3D AllocateAlignedBuffer (ScsiIoDevice, sizeof (EFI_SCSI_IN= QUIRY_DATA)); if (InquiryData =3D=3D NULL) { ScsiDeviceFound =3D FALSE; goto Done; } =20 + SenseData =3D AllocateAlignedBuffer ( + ScsiIoDevice, + sizeof (EFI_SCSI_SENSE_DATA) + ); + if (SenseData =3D=3D NULL) { + ScsiDeviceFound =3D FALSE; + goto Done; + } + // // Using Inquiry command to scan for the device // InquiryDataLength =3D sizeof (EFI_SCSI_INQUIRY_DATA); - SenseDataLength =3D 0; + SenseDataLength =3D sizeof (EFI_SCSI_SENSE_DATA); ZeroMem (InquiryData, InquiryDataLength); + ZeroMem (SenseData, SenseDataLength); =20 MaxRetry =3D 2; for (Index =3D 0; Index < MaxRetry; Index++) { Status =3D ScsiInquiryCommand ( &ScsiIoDevice->ScsiIo, SCSI_BUS_TIMEOUT, - NULL, + SenseData, &SenseDataLength, &HostAdapterStatus, &TargetStatus, (VOID *) InquiryData, &InquiryDataLength, FALSE ); if (!EFI_ERROR (Status)) { + if ((HostAdapterStatus =3D=3D EFI_SCSI_IO_STATUS_HOST_ADAPTER_OK) && + (TargetStatus =3D=3D EFI_SCSI_IO_STATUS_TARGET_CHECK_CONDITION) = && + (SenseData->Error_Code =3D=3D 0x70) && + (SenseData->Sense_Key =3D=3D EFI_SCSI_SK_ILLEGAL_REQUEST)) { + ScsiDeviceFound =3D FALSE; + goto Done; + } break; } if ((Status =3D=3D EFI_BAD_BUFFER_SIZE) || (Status =3D=3D EFI_INVALID_PARAMETER) || @@ -1376,8 +1395,9 @@ DiscoverScsiDevice ( =20 ScsiDeviceFound =3D TRUE; =20 Done: + FreeAlignedBuffer (SenseData, sizeof (EFI_SCSI_SENSE_DATA)); FreeAlignedBuffer (InquiryData, sizeof (EFI_SCSI_INQUIRY_DATA)); =20 return ScsiDeviceFound; } --=20 2.14.1.3.gb7cf6e02401b _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel