Concurrency verification behavior in QVL Impacted by QVE Policy

[ChengyuZhu6]

We have observed that the concurrency logic in QVL is being influenced by QVE policy. This behavior seems unintended and could lead to inconsistent handling of concurrent verifiction requests in QVL.

Expected Behavior

The qve_policy is designed to impact QVE verification exclusively. Ideally, qve_policy should not affect the QVL's functionality.

Current Behavior

Currently, QVL processes received verification requests serially by default. The default value of qve_policy is set to SGX_QL_PERSISTENT (which is equivalent to SGX_QL_DEFAULT). However, when we configure the qve_policy value to SGX_QL_PERSISTENT_QVE_MULTI_THREAD, QVL is capable of processing verification requests concurrently.

SGXDataCenterAttestationPrimitives/QuoteVerification/dcap_quoteverify/sgx_dcap_quoteverify.cpp

Lines 504 to 515 in 45554a7

	//untrsuted quote verification
	//
	else {
	if (tee_type == SGX_EVIDENCE)
	class_type = CLASS_SGX_QVL;
	if (tee_type == TDX_EVIDENCE)
	class_type = CLASS_TDX_QVL;
	}
	if (g_qve_policy == SGX_QL_PERSISTENT || g_qve_policy == SGX_QL_EPHEMERAL) {
	std::lock_guard<std::mutex> lock(qve_mutex);

[hyjiang]

This is by design because we want to guarantee the default behavior of QVL/QvE keep unchanged with old DCAP release. In the other words, the legacy mode SGX_QL_PERSISTENT and SGX_QL_EPHEMERAL don't have multiple thread support from the very beginning.

So we added two new modes SGX_QL_EPHEMERAL_QVE_MULTI_THREAD and SGX_QL_PERSISTENT_QVE_MULTI_THREAD to improve the performance. If you have performance requirement, please use these 2 new modes.

[ChengyuZhu6]

This is by design because we want to guarantee the default behavior of QVL/QvE keep unchanged with old DCAP release. In the other words, the legacy mode SGX_QL_PERSISTENT and SGX_QL_EPHEMERAL don't have multiple thread support from the very beginning.

So we added two new modes SGX_QL_EPHEMERAL_QVE_MULTI_THREAD and SGX_QL_PERSISTENT_QVE_MULTI_THREAD to improve the performance. If you have performance requirement, please use these 2 new modes.

Thanks for your information.

[mythi]

Ideally, qve_policy should not affect the QVL's functionality.

@hyjiang The case here is that the user has explicitly chosen not to use QVE so why they still need to care about the load policy

[hyjiang]

Ideally, qve_policy should not affect the QVL's functionality.

@hyjiang The case here is that the user has explicitly chosen not to use QVE so why they still need to care about the load policy

You're right, the overall solution doesn't seem perfect at the moment. This is because the previous QVL/QvE did not support multithreading, and when we consider adding multithreading support, we need to keep the original behavior unchanged.
So you need to set a different mode as a switch, as a result, the existing loading QvE policy API has been reused.

[mythi]

So you need to set a different mode as a switch, as a result, the existing loading QvE policy API has been reused.

Do you have the behavior documented so that we could point our code to it?