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.
AstralStorm · 9h ago
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.
mike_hearn · 4h ago
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.
iforgotpassword · 9h ago
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.
sublimefire · 9h ago
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.
iforgotpassword · 7h ago
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.
noname120 · 9h ago
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.
Intel is keeping SGX on servers and no longer offering it on non-server chips like workstations and laptops.
Lirael · 9h ago
SGX tried to solve a real problem—trust in cloud computing—but ended up being too complex, too closed, and too reliant on Intel's infrastructure. Once kernel-level side-channel attacks became practical, the core premise cracked. Ironically, SGX can also hide malware, making it a double-edged sword.
Most of them require physical access so it is not the same as some log4j vuln.
walterbell · 8h ago
Per article, physical access is within SGX threat model.
bjackman · 8h ago
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.
lostmsu · 2h ago
It could have been used for a distributed cloud over consumer hardware.
underdeserver · 9h ago
Should be (2022).
bananapub · 6h ago
because it kept getting owned, then fixed, then owned again
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.
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.
Case in point: TeleMessage. Supposedly E2E-Encrypted message archival turns out to be a plain text database on some servers. Surprised Pikachu face.
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.
> 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...
Intel is keeping SGX on servers and no longer offering it on non-server chips like workstations and laptops.
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.