pkcs11_1021 fails when OP-TEE core is configured with MBedTLS

[jforissier]

Test platform QEMUv8 with make CFG_CRYPTOLIB_NAME=mbedtls CFG_CRYPTOLIB_DIR=lib/libmbedtls run:

$ xtest pkcs11_1021
Test ID: pkcs11_1021
Run test suite with level=0

TEE test application started over default TEE instance
######################################################
#
# regression+gp+pkcs11
#
######################################################

* pkcs11_1021 PKCS11: RSA PKCS key generation and signing
o pkcs11_1021.1 RSA-1024: Generate key pair
pkcs11_1000.c:6439: rv has an unexpected value: 0x6 = CKR_FUNCTION_FAILED, expected 0x0 = CKR_OK
  pkcs11_1021.1 FAILED
  pkcs11_1021 FAILED
+-----------------------------------------------------
Result of testsuite regression+gp+pkcs11 filtered by "pkcs11_1021":
pkcs11_1021.1 FAILED first error at pkcs11_1000.c:6439
pkcs11_1021 FAILED
+-----------------------------------------------------
8 subtests of which 1 failed
1 test case of which 1 failed
2307 test cases were skipped
TEE test application done!

Secure console has:

E/TA:  tee2pkcs_add_attribute:379 Failed TEE attribute 0xc0000630 for 0x126/EXPONENT_1

0xc0000630 is TEE_ATTR_RSA_EXPONENT1 which is one of the RSA CRT parameters, optional as per the GP spec.

With this patch:

diff --git a/ta/pkcs11/src/processing.c b/ta/pkcs11/src/processing.c
index 08374513..835f3b28 100644
--- a/ta/pkcs11/src/processing.c
+++ b/ta/pkcs11/src/processing.c
@@ -336,8 +336,10 @@ enum pkcs11_rc alloc_get_tee_attribute_data(TEE_ObjectHandle tee_obj,
        uint32_t sz = 0;

        res = TEE_GetObjectBufferAttribute(tee_obj, attribute, NULL, &sz);
-       if (res != TEE_ERROR_SHORT_BUFFER)
+       if (res != TEE_ERROR_SHORT_BUFFER) {
+               TEE_Panic(0xBADBEEF);
                return PKCS11_CKR_FUNCTION_FAILED;
+       }

        ptr = TEE_Malloc(sz, TEE_USER_MEM_HINT_NO_FILL_ZERO);
        if (!ptr)

...the following stack trace is produced:

E/TC:? 0 TA panicked with code 0xbadbeef
E/LD:  Status of TA fd02c9da-306c-48c7-a49c-bbd827ae86ee
E/LD:   arch: aarch64
E/LD:  region  0: va 0x40004000 pa 0x0e326000 size 0x002000 flags rw-s (ldelf)
E/LD:  region  1: va 0x40006000 pa 0x0e328000 size 0x008000 flags r-xs (ldelf)
E/LD:  region  2: va 0x4000e000 pa 0x0e330000 size 0x001000 flags rw-s (ldelf)
E/LD:  region  3: va 0x4000f000 pa 0x0e331000 size 0x004000 flags rw-s (ldelf)
E/LD:  region  4: va 0x40013000 pa 0x0e335000 size 0x001000 flags r--s
E/LD:  region  5: va 0x40014000 pa 0x0e36e000 size 0x002000 flags rw-s (stack)
E/LD:  region  6: va 0x40016000 pa 0x7bcf9000 size 0x001000 flags rw-- (param)
E/LD:  region  7: va 0x40017000 pa 0x7bcba000 size 0x001000 flags rw-- (param)
E/LD:  region  8: va 0x40023000 pa 0x00001000 size 0x02a000 flags r-xs [0] .ta_head .text .eh_frame .rodata .gnu.hash .dynsym .dynstr .hash .rela.dyn
E/LD:  region  9: va 0x4004d000 pa 0x0002b000 size 0x00e000 flags rw-s [0] .dynamic .got .rela.got .data .bss
E/LD:   [0] fd02c9da-306c-48c7-a49c-bbd827ae86ee @ 0x40023000 (optee_os/out/arm/ta/pkcs11/fd02c9da-306c-48c7-a49c-bbd827ae86ee.elf)
E/LD:  Call stack:
E/LD:   0x4002b4c8 alloc_get_tee_attribute_data at optee_os/ta/pkcs11/src/processing.c:340
E/LD:   0x4002b56c tee2pkcs_add_attribute at optee_os/ta/pkcs11/src/processing.c:366
E/LD:   0x4002f2ac tee2pkcs_rsa_attributes at optee_os/ta/pkcs11/src/processing_rsa.c:514
E/LD:   0x4002b900 entry_generate_key_pair at optee_os/ta/pkcs11/src/processing.c:512
E/LD:   0x40023d70 TA_InvokeCommandEntryPoint at optee_os/ta/pkcs11/src/entry.c:350
E/LD:   0x40038730 entry_invoke_command at optee_os/lib/libutee/arch/arm/user_ta_entry.c:370
E/LD:   0x400318d8 __ta_entry at optee_os/out/arm/export-ta_arm64/src/user_ta_header.c:48

...which makes me think the bug is in the PKCS#11 TA which doesn't expect the attribute to be absent (actually, TEE_GetObjectBufferAttribute() returns TEE_SUCCESS with sz == 0 which would indicate TEE_ATTR_RSA_EXPONENT1 is present but equal to zero? weird... but in any case we don't have a non-zero attribute so the code in alloc_get_tee_attribute_data() looks wrong).

@etienne-lms any idea?

[Ykidia]

There is still no any solution/workaround for this? Got the same in three tests:

* pkcs11_1021 PKCS11: RSA PKCS key generation and signing
o pkcs11_1021.1 RSA-1024: Generate key pair
pkcs11_1000.c:6443: rv has an unexpected value: 0x6 = CKR_FUNCTION_FAILED, expected 0x0 = CKR_OK
  pkcs11_1021.1 FAILED
  pkcs11_1021 FAILED
 
* pkcs11_1022 PKCS11: RSA PSS key generation and signing
o pkcs11_1022.1 RSA-1024: Generate key pair
pkcs11_1000.c:6844: rv has an unexpected value: 0x6 = CKR_FUNCTION_FAILED, expected 0x0 = CKR_OK
  pkcs11_1022.1 FAILED
  pkcs11_1022 FAILED
 
* pkcs11_1023 PKCS11: RSA OAEP key generation and crypto operations
o pkcs11_1023.1 RSA-1024: Generate key pair
pkcs11_1000.c:7207: rv has an unexpected value: 0x6 = CKR_FUNCTION_FAILED, expected 0x0 = CKR_OK
  pkcs11_1023.1 FAILED
  pkcs11_1023 FAILED

[jforissier]

Issue still present, but will not be applicable anymore if we decide to remove support for MBedTLS in the core as suggested in jenswi-linaro#11.

[etienne-lms]

I cannot reproduce the issue initially described here, running xtest pkcs11_1021 with core built with mbedtls as crypto lib, based on latest OP-TEE 4.4.0. That said, xtest pkcs11_1021 still fails but for another reason IMO that is addressed by OP-TEE/optee_test#763.

I also see that xtest pkcs11_1026 also fails when core is built with mbedtls as crypto lib. The private key loaded in mbedtls has nul DP and DQ values which is weird. That said, i think it's not related to the issue initially described here. I'll investigate further to find the root cause.

FYI regarding xtest results when core is built with mbedtls as crypto lib, I found no other issue but the 2 mention in this comment when running xtest regression+pkcs11+pg tests.