[CometLake-S] Intel Software Guard Extension (SGX) Validation failed.

[RichardLn]

When trying to validate SGX enclave, the remote attestation respond Intel-SA-00289 and Intel-SA-00334. We also got the same issue when trying to run the linux-sgx EPID RemoteAttestation sample code (https://github.com/intel/sgx-ra-sample). The Remarks below are our test environment, and it seems that all the cases are failed.

We did some research on these two issues:

1. Intel-SA-00289 (PlunderVolt):  https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00289.html   

2. Intel-SA-00334 (Load Value Injection): https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00334.html

3. Intel® SGX Attestation Technical Details 

4. How to mitigate common SAs reported by IAS during remote attestation

We followed some recommendation  within these pages, but the fact is that the issues are still existed.

Besides, we found that there are two different SKU of CPU (Embedded and PC/Client ). Does it mean only Embedded SKU will not be affected by these issues while the other SKU will still be affected even if we follow the recommendations? Although they all support SGX feature according to the Product Specifications.

• IoT Plaforms Gold Deck doc#614068

The attachments are log from sgx-ra-sample (both server and client side), system information and test flow.

Would you please help us to clarify these issues?

A prompt reply would help us greatly.

Best Regards

Remark:

• CPU: Intel(R) I9-10900T & 10900K (Stepping: Q0, CPUID: A0655), I3-10100T
• Mother Board:  Intel Comet Lake RVP with CML-H PCH (QDF: SRH13)
• SGX driver: sgx_linux_x64_driver_1.41
• SGX SDK:   sgx_linux_x64_sdk_2.13.103.1
• OS: Clean Ubuntu 18.04 (or 20.04) LTS
• BIOS: Intel CML_3044
• BIOS Setting:

1.     CPU Lock configuration -> overclocking lock -> Enabled 
2.     CPU configuration ->  Software Guard Extension (SGX) -> Enabled
3.     Disable Hyper-threading.
4.     Disable Internal GFX

P.s. Some z490 Motherboards are also used for testing (e.g., ROG STRIX Z490-I GAMING, ROG MAXIMUS XII FORMULA)

[JesusG_Intel · Accepted solution]

Hello Richard,

Since your processor is vulnerable to SA-0034: Load Value Injection, you will always get the SW_HARDENDING_NEEDED result. The reason is that the backend, IAS, cannot verify that the platform has the mitigations in place for this SA.

Since SA-0034 is there, the other SAs are also reported back. IAS assumes that since the platform is vulnerable to SA-0034, the platform can be compromised and the other SA mitigations can be faked. So, even though you have mitigated SA-00289, the fact that SA-0034 is always there, SA-00289 will always be reported back too.

Refer to this article for more details: Receiving ISV Enclave Trust Status as "Enclave NOT TRUSTED - Reason: CONFIGURATION_AND_SW_HARDENING_NEEDED" During Remote Attestation

Note	All Security Advisories must be mitigated in order to remove any of the advisories. If you mitigate only one of the security advisories, it will still show up because not all of them were mitigated.

Your trust policy must determine whether to trust the enclave based on its ISVSVN (enclave version).

Sincerely,

Jesus G.

Intel Customer Support

[RichardLn]

Hi,

Thank you very much for your reply.

The following is some of my views:

   The CPU that we used is vulnerable to SA-0034, it will always get SW_HARDENDING_NEEDED return from IAS.  Since SA-00334 is there, we may also get other Advisories unless these vulnerabilities (SA-00334 and SA-00289) are solved  at the same time.

   In the sgx-ra-sample code, we can find a variable Min_ISVSVN which is used to enforce a minimum enclave version. Does this represent our trust policy? (Only when the ISVSVN of enclave is greater than the Min_ISVSVN will be trusted) 

   But the SA-00334 still exists after we do this.

[JesusG_Intel]

Hello Richard,

You are exactly right. The Min_ISVSVN is used in a policy to confirm that the enclave meets a minimum software version. This is explained further in Sgx-ra-sample/enclave_verify.c.

The purpose of the report from IAS is to provide the relying 3rd party information on the potential security vulnerabilities found on the enclave's platform. It is up to the relying 3rd party to set policies on whether to trust the enclave's platform based on the report.

For example, the relying 3rd party may care about some SAs and not others.

SA-0034 will continue to show up for that processor but the relying 3rd party can choose to ignore that SA if it knows that the enclave's platform is otherwise trustworthy enough.

Sincerely,

Jesus G.

Intel Customer Support

[JesusG_Intel]

This thread has been marked as answered and Intel will no longer monitor this thread. If you want a response from Intel in a follow-up question, please open a new thread.