If I'm understanding this correctly, it doesn't provide any kind of protection against a compromised operating system. How could it? The encryption is transparent to applications, so the OS could just lie and say that encryption is enabled.
What it does provide is protection against hardware attacks like memory bus snooping, or chilling and extracting DRAM modules.
Not necessarily, depends on what exactly you put in the enclave. It's possible to design a system where the OS lives outside the enclave in untrusted memory. The assurance that your enclave memory is protected is provided by the hardware, and can be confirmed remotely by an attestation protocol. For more information I would recommend checking out a paper by Microsoft Research called "Shielding applications from an untrusted cloud with Haven" from OSDI' 14.
Sure, but that's a totally different mechanism than the one discussed in this link. According to the presentation, it uses ephemeral keys that are randomly generated at boot, so it doesn't help with things like remote attestation.
No, the whole point of SGX is that there is a unique key burned into each machine from which other keys are derived that allows you to attest the contents of each enclave's memory.
I thought we were talking about the "Memory Encryption Engine", which is what the link is describing. Slide 7 says the keys are "randomly generated at reset".
The OS can't lie because it is unable to generate the same keys the hardware uses. Without those keys, the enclave can't decrypt whatever sensitive data it sealed earlier.
What it does provide is protection against hardware attacks like memory bus snooping, or chilling and extracting DRAM modules.