costan

Re: 1 - I re-read the relevant SDM sections, and saw that there is no requirement that the new upgrade version exceeds the current microcode version. Thank you very much for pointing that out! The next published revision will have the fix.

Do you have any public references for 3 and 4? That looks like it'd help make the case that SGX rests on very complex and unstable foundations.

Instead, I think that a bunch of MBAs showed up and decided SGX is security, security is an enterprise thing, so SGX must be pay-to-play. For whatever it's worth, I think the SGX designers did a pretty good job of separating the objectionable parts from the rest of the design.

For example, the EPID homebrew crypto is all in software, so Intel can change the algorithm without hardware mods or microcode updates.

Also, the way they set up the Launch Enclave gives Intel time until the very last minute to not be a douche. They still have the option to release a permissive Launch Enclave that only includes the checks needed to keep attestation secure.

The SGX design that doesn't come from MBAs is quite clean, given that it addresses the multi-layered crap pile that is X86. There are some cool tricks in there.

If the OS is evil and you don't do attestation, it can emulate SGX and run your code in a simulated enclave environment where EGETKEY returns keys that the OS knows about.

If the OS is not evil, you can use process isolation to generate and protect the keys.

Based on public docs, you can't do DRM decoding in an enclave. But you can execute some complex logic to validate a user's license and decide whether you want to release the encryption key to the ME or GPU.

Details: if the key used to sign architectural enclaves (like the Launch Enclave) would leak, this would completely break SGX. Anyone with the key could create their own Quoting Enclave and the guarantees behind software attestation would go down the drain.

A Xeon implementation would have to secure the QPI links between the CPU chips. These run at significantly higher speeds than DRAM, so the current MEE design would likely not be able to keep up. Also, a Xeon implementation would have to somehow have the chips mutually authenticate each other.

That being said, I wouldn't be surprised if Intel was trying to see if they can get away with the licensing bs in desktops before committing resources to tackling the challenges that I mentioned above.