Any plan for GP filtered test cases

[yguoqing]

Hello

I have integrate the TEE_Initial_Configuration-Test_Suite_v1_1_0_4-2014_11_07 for Extended test (Global Platform tests). I found still have some GP test cases filtered in optee_test Makefike. Any plan to enable these test cases?

.PHONY: patch-filter patch-filter: @echo "INFO: Filter some tests" $(call patch-filter-one,7038) $(call patch-filter-one,7522) $(call patch-filter-one,7538) $(call patch-filter-one,7540) $(call patch-filter-one,7546) $(call patch-filter-one,7557) ....................

Thanks.

[jbech-linaro]

Hi @yguoqing ,

We have no such plans. Having that said, as strange as it may sound, Linaro as such doesn't have access to the GP tests. But some of our members have. So there are some people working with Linaro that has the ability and indeed are running the GP tests on OP-TEE.

Having that said, if you have time and are willing to work with the test you are mentioning, then we would be more than happy to enable those when you know it is working without any regressions using official OP-TEE gits.

You can read more about it in this blog post the difference between having access to GP test or not here: http://www.linaro.org/blog/core-dump/testing-a-trusted-execution-environment

[yguoqing]

Hi @jbech-linaro ,

Thanks for your kindly support. I am engaged in porting OP-TEE on our platform. So need to verify it using GP Compliance Test Suite. I have GlobalPlatform TEE Initial Configuration Compliance Test Suite v1.1.0.4 in my hand. And already extend this test suite into xtest. All test cases passed except the filtered test cases which I mentioned above. I have checked the commits on this git. The latest commit fix bugs on these filtered test cases is below one. This is my reason to file this issue.

Enable 9000 tests related Invoke_Crypto_AsymmetricDecrypt … 3 issues are fixed:

• RSA crypto key (TEE_ATTR_RSA_MODULUS_VALUE01 / TEE_ATTR_RSA_PRIVATE_EXPONENT_VALUE01) results in an encrypted equal to 0 which is wrong. This is because TEE_ATTR_RSA_MODULUS_VALUE01 is truncated. This patch restores the correct value, according to TEE_Crypto_API_operationsDescriptions.html
• The number to encrypt, DATA_FOR_CRYPTO1, starts with a 0, and is a 96 bytes number. That means it is the same number as the one of 95 bytes without the first 0. When checking encode-decode returns the same result as the original input, the first leading 0s are not taken into account in case of NOPAD encryption.
• Invoke_Crypto_AsymmetricDecrypt(): it expects that the encrypted has the same length as the initial message. In the case of RSA-2048 bits, the encrypted of a 64bytes number is 256bytes long. This is now taken into account

Enabled tests are: 9053 9074 9081 9087 9092 9104 9111 9145 9146 9147 9148 9149 9181 9182 9183 9184 9186 9187 9195 9196

Reviewed-by: Jerome Forissier jerome.forissier@linaro.org Tested-by: Pascal Brand pascal.brand@linaro.org (QEMU) Signed-off-by: Pascal Brand pascal.brand@st.com

I will check further for the filtered test cases. Thanks again.

[jbech-linaro]

@yguoqing is this still something you are committed to look into?

[yguoqing]

Hi @jbech-linaro

Close it now, thanks