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.
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.
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.
Intel is keeping SGX on servers and no longer offering it on non-server chips like workstations and laptops.
> 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...
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.
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!
I wonder how readily things like this are known within the HW security community?
walterbell•9mo ago
sublimefire•9mo ago
walterbell•9mo ago
anonymousDan•9mo ago
walterbell•9mo ago
anonymousDan•9mo ago