Why Intel Deprecated SGX? | Hacker News Reader

Why Intel Deprecated SGX?

hardenedvault.net

22 pointsricecat21 comments

Pretty incoherent article. Not sure what point they are trying to make about the threat model of SGX. SGX was/is a groundbreaking attempt to solve a very difficult problem IMO. TEEs are still an active area of research that has benefited massively from the availability of an actual implementation in mainstream processors. And most other CPU manufacturers are also offering their own flavour of TEE, many of which have learned lessons from SGX.

The point about the threat model of SGX is that insulating an enclave with it does nothing to protect the code actually handling the data from the enclave. It really does not even protect against firmware side attacks. For that, TPM attestation is just as good.

At some point, somewhere, data processed by the SGX enclave has to pass through the usual VTd or such. Unless SGX enclave is used to feed data directly into hardware, in which case the weak point is the firmware and bus instead.

If it ensured no side channel attacks, it would be useful for some operations. But it does not therefore it isn't.

It was touted as making cloud computing secure. How anyone could actually believe this is beyond me. The cloud provider has physical access to the host machine. For all I know it could all be smokes and mirrors, emulated on a C64, while all my data is getting exfiltrated. The only people who ever bought into this is cryptobro crackheads and government contractors doing it for compliance bullshit. Up to 0% of cloud customers went as far as to even try to verify the thing does what it says it does.

Case in point: TeleMessage. Supposedly E2E-Encrypted message archival turns out to be a plain text database on some servers. Surprised Pikachu face.

This is some tinfoilhat stuff. An extreme suggestion that a cloud provider would physically open up machines and exfiltrate the keys so that they could then read the memory of a customer workload, for what reason? Remember that hardware is virtualised and makes it difficult to pin point which server is running what. Not using such tech makes it easier for the cloud provider to inspect memory so that is not a better approach.

If you argue that you can trust the cloud provider not to be malicious, you also just argued that you don't need SGX at all. No tinfoil hat required.

And yes, not using that tech is not a better approach then, but not worse either. But better in the way that Intel doesn't need to build convoluted shit into their cpus that might actually worsen security through exploits.

SGX is very useful. Source: I built a product that made it easier to use and we explored a lot of use cases as part of that.

Firstly yes SGX is designed to block firmware attacks. That's a part of the threat model indeed.

Secondly, you can't feed data from SGX enclaves directly to hardware devices. It's encrypted data in, encrypted data out. Of course, data must pass through the untrusted host OS and hypervisor, but that is no problem, it's how it's designed to work. That's why the clients of the enclave handshake with it using remote attestation.

You can block side channel attacks with SGX if you are careful. The enclave transitions do clear uarch state in the ways needed, the rest is app-level stuff (but it has to be).

I used to see a lot of confusion about stuff like SGX because some people don't realize it's only intended to be used with remote attestation. If you don't have a smart client that's remotely attesting the enclave over a network, it isn't going to get you anything. That requires changes to app architectures.

From Wikipedia[1]:

> A pivot by Intel in 2021 resulted in the deprecation of SGX from the 11th and 12th generation Intel Core processors, but development continues on Intel Xeon for cloud and enterprise use.

[1] https://en.wikipedia.org/wiki/Software_Guard_Extensions#cite...

Headline is missing important context:

Intel is keeping SGX on servers and no longer offering it on non-server chips like workstations and laptops.

Warning: the article is full of acronyms. Despite having section titles like "SGX Basics" unless you are familiar with terms like EPID, e-Fuse, iclsClient and many more, you aren't going to get much from it beyond "Intel dropped SGX for non-server CPU's in 2022".

> Chipworks offers $50-250k to fully extract the eFUSE of one Intel i5 processor, so the eFUSE content is encrypted by a master key (called “global wrapping logic key” in the patent).

I wonder how readily things like this are known within the HW security community?

SGX may be a record holder for exploits, https://hn.algolia.com/?query=sgx

Most of them require physical access so it is not the same as some log4j vuln.

Per article, physical access is within SGX threat model.

About 2 of those are actual exploits?

For some definition of 2?

  Intel SGX Fuse Key0, a.k.a. Root Provisioning Key Extracted by Researchers
  Plundervolt: Software-Based Fault Injection Attacks Against Intel SGX 
  SGX-Bomb: Locking Down the Processor via Rowhammer Attack
  Foreshadow: Extracting the Keys to the Intel SGX Kingdom
  ÆPIC Leak: SGX, Intel’s data fortress, has been breached yet again
  Intel SGX defeated yet again–this time thanks to on-chip power meter
  SGAxe and Crosstalk: Plundering of crypto keys from ultrasecure SGX 
  Spectre Attack on SGX PoC

Thanks - many of those didn't show up on your original link.

This never made any sense to me for consumers.

Enclaves and confidential compute are about the owner of the physical device giving up power and handing it to a remote entity.

In the case of SGX on consumer hardware that usually meant consumers giving up power to Netflix or whoever via DRM bullshit.

On the other hand, TDX on server devices is mostly about cloud providers giving up power to their users. This is a fundamentally better use case for TEEs. So overall this makes sense to me.

Kinda annoying that this stuff is so complicated that they have to leave it out of cheaper parts but that also makes sense, this must be incredibly invasive stuff that increases the cost in so many areas.

It could have been used for a distributed cloud over consumer hardware.

That would be a neat usecase but it's not a slam dunk.

TEEs in theory eliminate the need for the user to trust the owner of the hardware. But for a cloud you need to eliminate the other direction too.

Cloud companies achieve this by... Spending a LOT of money on it. And the technical project of doing that is easier, because they control the whole host stack. I'm not sure it's technically feasible to achieve that in an environment where the host also needs to also support stuff like running Steam!

But still, maybe if you constrained the requirements enough it could be possible, it would have been a really cool thing to try!

because it kept getting owned, then fixed, then owned again

Should be (2022).

Reply on news.ycombinator.com