From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from IMSVA.IN.MEGATRENDS.COM (venus.amiindia.co.in [111.93.197.227]) (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 EDC931A1F49 for ; Wed, 7 Sep 2016 22:14:16 -0700 (PDT) Received: from IMSVA.IN.MEGATRENDS.COM (IMSVA.IN.MEGATRENDS.COM [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D2EC382047; Thu, 8 Sep 2016 10:44:28 +0530 (IST) Received: from IMSVA.IN.MEGATRENDS.COM (IMSVA.IN.MEGATRENDS.COM [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BBF3082046; Thu, 8 Sep 2016 10:44:28 +0530 (IST) Received: from webmail.amiindia.co.in (venus2.in.megatrends.com [10.0.0.7]) by IMSVA.IN.MEGATRENDS.COM (Postfix) with ESMTPS; Thu, 8 Sep 2016 10:44:28 +0530 (IST) Received: from VENUS1.in.megatrends.com ([fe80::951:7975:6ecf:eae5]) by Venus2.in.megatrends.com ([fe80::2002:4a07:4f17:c09b%14]) with mapi id 14.03.0248.002; Thu, 8 Sep 2016 10:44:11 +0530 From: Ramesh R. To: "Jin, Eric" , "Tian, Feng" , edk2-devel CC: Sandip Datta Roy , Srini Narayana , Sundaresan S , =?iso-2022-jp?B?UmV4S3VvIFsbJEIzVDJIQC4bKEJd?= Thread-Topic: BootableImageSupportTest\StorageSecurityCommandProtocolTest Thread-Index: AdH+rBKMD33ErVHaTU69l2RWRNE5FAAvq2BQAN3zvKAARX8+gABSqBWAAHcBbXAABSXB8ACW7XCA Date: Thu, 8 Sep 2016 05:14:14 +0000 Message-ID: References: <7F1BAD85ADEA444D97065A60D2E97EE538825C19@SHSMSX101.ccr.corp.intel.com> <7F1BAD85ADEA444D97065A60D2E97EE566D84D98@SHSMSX101.ccr.corp.intel.com> <7F1BAD85ADEA444D97065A60D2E97EE566D868BC@SHSMSX101.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.84.109] MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.1600-8.1.0.1054-22562.005 X-TM-AS-Result: No--30.332-5.0-31-10 X-imss-scan-details: No--30.332-5.0-31-10 X-TMASE-Version: IMSVA-9.1.0.1600-8.1.1054-22562.005 X-TMASE-Result: 10--30.332100-10.000000 X-TMASE-MatchedRID: dL10VBB8yocikhyG+/kfagwfhKwa9GwD9uT35pz6g+9PtLhlThdPENgd zIvxiwaNbHz0AlkPRBhzlDejG0i/AAt3e7z0WipRzNY33yIEF4YiyTnlwmHiN4y4GRSuWkc5r2u CWLzuQ0hfGsTIDPCjH4LgvQCbn1oUcQU/y6LUwwttzb3s8Aa1ZjlIA4KS6pW3bcPp/oilsshSk3 lvhd38XWz9EKa36MwEgCw7qhLLtqOYUs0GLpnEx7CvlllU7Dl1Vo4lwLFUdivFFXLA6hSaPB/XW BLkU7fukveXv4oHzKldMJdkEVI/X2sc+sfMagXiFdu9R6K8SzQg0L4Xy2OHleQIoW+okd7Jv7Gv 4sFeJD85Rg1eyvWfXXiAfP7G7VSTs/+w07Y/y4cwC4P4FOZlyNZKsq3DGpalECjYXm855HuQKG5 L/s++En+H+u5hF9w576fKgyVoW7XeWWO+WO023huZoNKc6pl+ZdKh+/+x0Y7IvQIyugvKdb0Nni rU4EvwBHwOCfYyy7dd0Dammt4NvJTh6178RNH0qbg9uWhLYLf2kudi1D33EudTjSOFC/vqo8WMk QWv6iWiS/Z4XNnZKK/dq3PF0Qgr3QfwsVk0UbslCGssfkpInQ== X-TMASE-SNAP-Result: 1.811037.0001-0-1-12:0,22:0,33:0,34:0,39:0-0 Subject: Re: BootableImageSupportTest\StorageSecurityCommandProtocolTest X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 05:14:17 -0000 Content-Language: en-US Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Eric, Memory Page size Minimum (MPSMIN) is not exposed in the UEFI Scope.=20 Any schedule when this issue would be address in the SCT tool ?=20 Thanks, Ramesh -----Original Message----- From: Jin, Eric [mailto:eric.jin@intel.com]=20 Sent: 05 September 2016 10:54 To: Tian, Feng; Ramesh R.; edk2-devel Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest "Memory Page size Minimum (MPSMIN)" is Controller Capability and impl-spec. Is it possible for high level driver to get this attribute in UEFI scope? To detect the LIST LENGTH with (>8) buffer size and then get the whole lis= t sounds like a reasonable method. For SCT to handle this case, change the code to if(Status =3D=3D EFI_SUCCES= S) ||(Status =3D=3D EFI_DEVICE_ERROR) || (Status =3D=3D EFI_WARN_BUFFER_TOO= _SMALL)){ Thanks Eric -----Original Message----- From: Tian, Feng=20 Sent: Monday, September 5, 2016 11:18 AM To: Ramesh R. ; edk2-devel ; Jin,= Eric Cc: Tian, Feng Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest Ramesh, I suspect even if you send the buffer size as 512 all the devices should re= turn EFI_SUCCESS as well. As for different NVMe device behavior for length 10, it may be different un= derstanding on spec. Eric,=20 Do you know how to handle such case in SCT? Thanks Feng -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Rame= sh R. Sent: Saturday, September 3, 2016 2:06 AM To: Tian, Feng ; edk2-devel ;= Jin, Eric Subject: Re: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocol= Test Hi Feng, Some Nvme devices returns EFI_DEVICE_ERROR for the SCT test code ( when the= buffer passed with 10 bytes) and that creates failure in the SCT report.=20 Some Nvme devices returns EFI_SUCCESS also.=20 All the devices return EFI_SUCCESS if the we send the buffer size as "Memor= y Page size Minimum (MPSMIN)" =20 Thanks, Ramesh -----Original Message----- From: Tian, Feng [mailto:feng.tian@intel.com]=20 Sent: 01 September 2016 8:12 To: Ramesh R.; edk2-devel; Jin, Eric Cc: Tian, Feng Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest I checked the ATA spec, it says the transfer length of "Trust-Send" ATA cmd= should be 512. But for NVMe and other SCSI device, I didn't see any length limitation on "= Security Protocol In" cmd with security protocol field 0 and security proto= col specific field 0. It seems user could pass in any length value to get security protocol infor= mation. And last, user could get the whole one by passing down "supported s= ecurity protocol list length" + 8. Ramesh, do you meet real failure case? Eric, what's your opinion on this? Thanks Feng -----Original Message----- From: Ramesh R. [mailto:rameshr@ami.com]=20 Sent: Wednesday, August 31, 2016 1:20 AM To: Tian, Feng ; edk2-devel ;= Jin, Eric Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest Hi Feng, Any update or suggestion on this? Can we consider this as SCT tool issue = and would be fixed in next version ? Thanks, Ramesh -----Original Message----- From: Tian, Feng [mailto:feng.tian@intel.com]=20 Sent: 26 August 2016 12:54 To: Ramesh R.; edk2-devel; Jin, Eric Cc: Tian, Feng Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest Yes, I agree it's weird.=20 We are looking at this and will get back to you if we have findings. Thanks Feng -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Rame= sh R. Sent: Thursday, August 25, 2016 4:44 PM To: edk2-devel Subject: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest Hi, When the we run the "BootableImageSupportTest\StorageSecurityCommandProt= ocolTest" test on the NVME devices we are getting into error because of the= below testing code. // // According to TCG definition, when the Security Protocol field is set= to 00h, and SP // Specific is set to 0000h in a TRUSTED RECEIVE command, return securi= ty protocol // information. This Command is not associated with a security send com= mand // Status =3D StorageSecurityCommand->ReceiveData ( StorageSecurityCommand, BlockIo->Media->MediaId, 100000000, // Tim= eout 10-sec 0, // Sec= urityProtocol 0, // Sec= urityProtocolSpecifcData 10, // Pay= loadBufferSize, DataBuffer, // Pay= loadBuffer &RcvDataSize ); // // for ATA8-ACS SecurityProtocol, 512 byte is a request // if (IsAtaDevice) { if((Status =3D=3D EFI_DEVICE_ERROR) || (Status =3D=3D EFI_WARN_BUFFER= _TOO_SMALL)){ AssertionType =3D EFI_TEST_ASSERTION_PASSED; } else { AssertionType =3D EFI_TEST_ASSERTION_FAILED; } } else { if((!EFI_ERROR(Status)) || (Status =3D=3D EFI_WARN_BUFFER_TOO_SMALL))= { AssertionType =3D EFI_TEST_ASSERTION_PASSED; } else { AssertionType =3D EFI_TEST_ASSERTION_FAILED; } } For Ata devices, EFI_DEVICE_ERROR considered as valid error case and for th= e Nvme ( Non ATA) device it's considered as error. Could you please let us = know why there is difference in this case ?. Thanks, Ramesh _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel