Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Will SGX be deprecated? #760

Open
AlvinChen1028 opened this issue Nov 25, 2021 · 8 comments
Open

Will SGX be deprecated? #760

AlvinChen1028 opened this issue Nov 25, 2021 · 8 comments

Comments

@AlvinChen1028
Copy link

I check some of tigerlake CPUs, and find many tigerlake cpus don't support SGX, but some of them support TME (total memory encryption). Does it mean SGX will be deprecated?

@andyzyb
Copy link
Contributor

andyzyb commented Dec 22, 2021

SGX will only be supported on new server platforms. New client systems don't have SGX support.

@AlvinChen1028
Copy link
Author

@andyzyb How about TME? Any work need be done in SW side to adopt TME?
SGX or TME is also very important for client system, as the client systems are more easy to be attacked than server like Thunderbolt DMA attacking.

@daira
Copy link

daira commented Jan 16, 2022

SGX will only be supported on new server platforms. New client systems don't have SGX support.

To me (a security researcher who has followed the attacks against SGX in detail), it makes no sense to continue support for SGX on servers if it is being deprecated on desktops. Deprecating it on desktop chips is a clear signal that:

  • Protocol designers should not develop any further designs that rely on it;
  • Even Intel acknowledges that it can't be made secure.

The security arguments don't differ between desktop and servers. Is retaining it for servers just a face-saving exercise?

@DemiMarie
Copy link

SGX will only be supported on new server platforms. New client systems don't have SGX support.

To me (a security researcher who has followed the attacks against SGX in detail), it makes no sense to continue support for SGX on servers if it is being deprecated on desktops. Deprecating it on desktop chips is a clear signal that:

  • Protocol designers should not develop any further designs that rely on it;
  • Even Intel acknowledges that it can't be made secure.

The security arguments don't differ between desktop and servers. Is retaining it for servers just a face-saving exercise?

Personally, I am glad that new server platforms will have it. Signal makes use of it for private contact discovery, and doing this without SGX (or a similar technology) would be much more difficult. Also, SGX is a dependency of Intel’s Trusted Domain Extensions (TDX).

@Maxul
Copy link

Maxul commented Jan 28, 2022

Source: https://github.com/Maxul/Awesome-SGX-Open-Source/blob/master/SGX-vs-TDX.md

Fact: Intel has deprecated SGX in the 11th, 12th generations of Core processors [1] [2].

Q1: Was SGX completely deprecated by Intel?

A1: No. Only PC processors.

Q2: Why will Intel TDX replace Intel SGX?

Personally, I believe that Intel TDX is a good alternative to Intel SGX. TDX outperforms SGX for the following reasons:

  1. Compatibility: TDX provides VM abstraction, a natural fit for the cloud service provider.
    The VM abstraction can easily support any unmodified applications by a POSIX-compatible guest kernel or today's Unikernels [4]. Existing SGX LibOSes (Gamine [5] or Occlum [6]) are still working in progress to support various applications.

  2. Performance: TDX supports para-virtualization or even SR-IOV for high-performance I/O. On the contrary, SGX must involve expensive context switches for I/O intensive workloads. Although asynchrony was proven to assist, asynchrony has to bring more CPUs into busy looping.

  3. Security: TDX utilizes multi-key memory encryption (MKTME) and introduces a secure hypervisor (i.e., SEAM module) that minimizes the controlled-channel attacks than SGX.

  4. Utilization: SGX must statically partition the physical memory into two halves; the secure memory (i.e., enclave page cache or EPC) cannot be shared with the OS. TD (namely, encrypted VM) pages can be flexibly configured to be private, shared or public (unencrypted).

Given the above comparison, I do not see any wins for SGX. TDX supports remote attestation and memory encryption just like SGX does. Worse, recent scalable SGX on Xeon3 abandons memory integrity, making TDX and SGX almost the same security level. When TDX is released, SGX will probably be doomed in the long run.

Q3: Will Intel SGX be finally replaced by Intel TDX?

A3: Probably not. For two reasons:

  • As long as Intel still reuses SGX to assist the remote attestation of TDX [3].
  • SGX is pretty useful for micro-services such as key management services (KMS).

[1] https://cdrdv2.intel.com/v1/dl/getContent/634648

[2] https://cdrdv2.intel.com/v1/dl/getContent/655258

[3] https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trust-domain-extensions.html

[4] http://unikernel.org/

[5] https://github.com/gramineproject/gramine

[6] https://github.com/occlum/occlum

@VicoChern
Copy link

@ScottR-Intel ,
Based on the article, it seems both Intel SGX and Intel TDX are available for only Intel Xeon platform, how about the client platforms? Our customers are asking how to prevent the memory dumping attack for their clients, if the sensitive data in the memory are encrypted, then it makes the clients more secured. Does Intel have plan to support the memory encrypting on client platforms? Any information for that?

@ScottR-Intel
Copy link

Intel vPro Business Client platforms starting with 11th Gen, support Total Memory Encryption to encrypt memory. Here is more information on this feature: https://www.intel.com/content/dam/www/central-libraries/us/en/documents/white-paper-intel-tme.pdf . This feature provides protection against hardware snooping/memory dumping attacks. Unfortunately we currently don’t have any technology on our client platforms against privileged software dumping memory .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants