From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 5582F1A1E5A for ; Wed, 31 Aug 2016 20:47:37 -0700 (PDT) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga102.jf.intel.com with ESMTP; 31 Aug 2016 20:47:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,265,1470726000"; d="scan'208";a="3409989" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga005.jf.intel.com with ESMTP; 31 Aug 2016 20:47:36 -0700 Received: from fmsmsx115.amr.corp.intel.com (10.18.116.19) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 31 Aug 2016 20:47:36 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by fmsmsx115.amr.corp.intel.com (10.18.116.19) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 31 Aug 2016 20:47:36 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.102]) by shsmsx102.ccr.corp.intel.com ([169.254.2.109]) with mapi id 14.03.0248.002; Thu, 1 Sep 2016 11:47:34 +0800 From: "Jin, Eric" To: "Tian, Feng" , Ramesh R. , edk2-devel Thread-Topic: BootableImageSupportTest\StorageSecurityCommandProtocolTest Thread-Index: AdH+rBKMD33ErVHaTU69l2RWRNE5FAAvq2BQAN3zvKAARX8+gAABA2tg Date: Thu, 1 Sep 2016 03:47:34 +0000 Message-ID: References: <7F1BAD85ADEA444D97065A60D2E97EE538825C19@SHSMSX101.ccr.corp.intel.com> <7F1BAD85ADEA444D97065A60D2E97EE566D84D98@SHSMSX101.ccr.corp.intel.com> In-Reply-To: <7F1BAD85ADEA444D97065A60D2E97EE566D84D98@SHSMSX101.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.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, 01 Sep 2016 03:47:37 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For the TRUSTED RECEIVE commands of the ATA8-ACS command,=20 in the ATA8-ACS spec, the total data length shall be 512 bytes. Pad bytes a= re appended as needed to meet this requirement. Pad bytes shall have a valu= e of 00h. For the SECURITY PROTOCOL IN commands of the SPC-4 command, In the SPC-4 spec, when INC_512 is 0, the ALLOCATION LENGTH field expresses= the number of bytes to be transferred. It means any value. If the length is larger than 8 bytes, the byte 6-7 indicate the SUPPORTED S= ECURITY PROTOCOL LIST LENGTH. If the length is larger than (SECURITY PROTOC= OL LIST LENGTH + 8), all are returned and plus the pad data. Best Regards Eric -----Original Message----- From: Tian, Feng=20 Sent: Thursday, September 1, 2016 10:42 AM 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