From: "Jin, Eric" <eric.jin@intel.com>
To: "Tian, Feng" <feng.tian@intel.com>, Ramesh R. <rameshr@ami.com>,
edk2-devel <edk2-devel@lists.01.org>
Subject: Re: BootableImageSupportTest\StorageSecurityCommandProtocolTest
Date: Mon, 5 Sep 2016 05:23:30 +0000 [thread overview]
Message-ID: <DA72DC7456565B47808A57108259571F60A1C108@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <7F1BAD85ADEA444D97065A60D2E97EE566D868BC@SHSMSX101.ccr.corp.intel.com>
"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 list sounds like a reasonable method.
For SCT to handle this case, change the code to
if(Status == EFI_SUCCESS) ||(Status == EFI_DEVICE_ERROR) || (Status == EFI_WARN_BUFFER_TOO_SMALL)){
Thanks
Eric
-----Original Message-----
From: Tian, Feng
Sent: Monday, September 5, 2016 11:18 AM
To: Ramesh R. <rameshr@ami.com>; edk2-devel <edk2-devel@lists.01.org>; Jin, Eric <eric.jin@intel.com>
Cc: Tian, Feng <feng.tian@intel.com>
Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest
Ramesh,
I suspect even if you send the buffer size as 512 all the devices should return EFI_SUCCESS as well.
As for different NVMe device behavior for length 10, it may be different understanding on spec.
Eric,
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 Ramesh R.
Sent: Saturday, September 3, 2016 2:06 AM
To: Tian, Feng <feng.tian@intel.com>; edk2-devel <edk2-devel@lists.01.org>; Jin, Eric <eric.jin@intel.com>
Subject: Re: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest
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.
Some Nvme devices returns EFI_SUCCESS also.
All the devices return EFI_SUCCESS if the we send the buffer size as "Memory Page size Minimum (MPSMIN)"
Thanks,
Ramesh
-----Original Message-----
From: Tian, Feng [mailto:feng.tian@intel.com]
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 protocol specific field 0.
It seems user could pass in any length value to get security protocol information. And last, user could get the whole one by passing down "supported security 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]
Sent: Wednesday, August 31, 2016 1:20 AM
To: Tian, Feng <feng.tian@intel.com>; edk2-devel <edk2-devel@lists.01.org>; Jin, Eric <eric.jin@intel.com>
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]
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.
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 Ramesh R.
Sent: Thursday, August 25, 2016 4:44 PM
To: edk2-devel <edk2-devel@lists.01.org>
Subject: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest
Hi,
When the we run the "BootableImageSupportTest\StorageSecurityCommandProtocolTest" 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 security protocol
// information. This Command is not associated with a security send command
//
Status = StorageSecurityCommand->ReceiveData (
StorageSecurityCommand,
BlockIo->Media->MediaId,
100000000, // Timeout 10-sec
0, // SecurityProtocol
0, // SecurityProtocolSpecifcData
10, // PayloadBufferSize,
DataBuffer, // PayloadBuffer
&RcvDataSize
);
//
// for ATA8-ACS SecurityProtocol, 512 byte is a request
//
if (IsAtaDevice) {
if((Status == EFI_DEVICE_ERROR) || (Status == EFI_WARN_BUFFER_TOO_SMALL)){
AssertionType = EFI_TEST_ASSERTION_PASSED;
} else {
AssertionType = EFI_TEST_ASSERTION_FAILED;
}
} else {
if((!EFI_ERROR(Status)) || (Status == EFI_WARN_BUFFER_TOO_SMALL)){
AssertionType = EFI_TEST_ASSERTION_PASSED;
} else {
AssertionType = EFI_TEST_ASSERTION_FAILED;
}
}
For Ata devices, EFI_DEVICE_ERROR considered as valid error case and for the 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
next prev parent reply other threads:[~2016-09-05 5:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-25 8:43 BootableImageSupportTest\StorageSecurityCommandProtocolTest Ramesh R.
2016-08-26 7:24 ` BootableImageSupportTest\StorageSecurityCommandProtocolTest Tian, Feng
2016-08-30 17:19 ` BootableImageSupportTest\StorageSecurityCommandProtocolTest Ramesh R.
2016-09-01 2:42 ` BootableImageSupportTest\StorageSecurityCommandProtocolTest Tian, Feng
2016-09-01 3:47 ` BootableImageSupportTest\StorageSecurityCommandProtocolTest Jin, Eric
2016-09-02 18:05 ` BootableImageSupportTest\StorageSecurityCommandProtocolTest Ramesh R.
2016-09-05 3:18 ` BootableImageSupportTest\StorageSecurityCommandProtocolTest Tian, Feng
2016-09-05 5:23 ` Jin, Eric [this message]
2016-09-08 5:14 ` BootableImageSupportTest\StorageSecurityCommandProtocolTest Ramesh R.
2016-09-08 5:29 ` BootableImageSupportTest\StorageSecurityCommandProtocolTest Jin, Eric
2016-09-08 5:11 ` BootableImageSupportTest\StorageSecurityCommandProtocolTest Ramesh R.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DA72DC7456565B47808A57108259571F60A1C108@SHSMSX103.ccr.corp.intel.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox