Race Condition Case in Configuring Multiple Instances for PKCS#11 TA

[weizhaojiang]

Config PKCS#11 as below: #define TA_FLAGS (TA_FLAG_MULTI_SESSION | \ TA_FLAG_EXEC_DDR | \ TA_FLAG_INSTANCE_KEEP_ALIVE) If two applications call C_InitToken() concurrently, both instances load entry_ck_token_infofrom the database, update the information in their local memory, and then update the database. Without a mutex to protect the database, can this scenario lead to a race condition? Please help me to understand how above scenario can work well with current pkcs#11 TA. Thanks.

[etienne-lms]

The pkcs11 TA is a "single-instance" TA, that means only 1 instance of the TA is created and is invoked by all clients. That said, there was an issue in OP-TEE core, recently opened, that possibly led to creation of several instance of a "single-instance TAs", see https://github.com/OP-TEE/optee_os/issues/6801. It's been closed thanks to https://github.com/OP-TEE/optee_os/pull/6836.

The pkcs11 TA only processes 1 client command at a given time. There can be several clients having a session opened towards the TA, but when the TA processes a command from 1 client, commands invoked by other clients get a TEE_ERROR_BUSY response from OP-TEE core and are put in a waitqueue (in the Linux kernel) until the being processed command completes. This behavior is generic to at all TAs, it is a GP TEE requirement: Trusted Applications cannot process clients commands concurrently.

[weizhaojiang]

Thanks for the feedback. If the PKCS#11 TA can only operate as a single-instance, will it cause performance issues when multiple CAs try to perform cryptographic operations simultaneously? Some operations, such as RSA-2048 key generation, can take 1-2 seconds to complete, meaning other CAs would have to wait for the operation to finish before they can perform even lightweight operations. any consideration on that?

[etienne-lms]

Indeed you can face performance issues on such conditions.

[weizhaojiang]

Do you think it would be feasible for the PKCS#11 TA to support multiple instances? For example, we could use a mutex to ensure data consistency, but there might be other, better approaches. I'd like to understand how challenging it would be to implement this support.

[etienne-lms]

If you consider 2 PKCS#11 tokens, I agree they could be implemented as 2 instances of the pkcs11 TA (not to say it's straight forward). If you expect the same PKCS#11 token to be able to serve concurrently 2 client sessions, I don't see how to address that in the scope of a GP TEE compliant TA.

[weizhaojiang]

My case involves an application that owns a single token. It has two threads, both of which open a PKCS#11 session using the same token, it does have two sessions. One thread is responsible for generating a key, while the other thread uses that key to perform decryption. It works well with one single instance setting but it fails when enable multiple instances. I Randomly found the "No Token belongs to this App" which mean the Token is gone.

[weizhaojiang]

I will use the single instance if it's confirmed that the PKCS#11 TA is designed not to support multiple instances. Thanks for your support.