Per article, physical access is within SGX threat model.

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

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.

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.

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!