You are making a strange argument. Anything is a platform. A web browser is a platform. A tab in a browser is a platform. In CS, anywhere that code executes is a platform. If you want to say SGX is a platform, that's perfectly fine. But SGX, SME, and SEV all attempts to tackle the same problem. Encryption of memory spaces vulnerable to attack. But that doesn't mean this puts them on the same level, with the same features, and the same end results.
This is not just catch-up like you insist. Whether or not any of the 3 are trusted execution platforms is completely up to your perspective, application design, and end goals. Running parts of an application in a trusted execution environment does not make it a platform for the application, because where is the rest of the application running? SGX and SME are designed to provide hardened I/O environments for specific application data in memory.
SGX and SME have the same goal, but because of the way it is done, I would say SGX's approach is better when viewed from the security of specific application execution because SGX is able to protect that data all the way through the stack.
SGX, utilizing enclaves, runs the security engine on the
processor itself. AMD, using SME, is simply encrypting portions of memory from the OS at boot time. This means SME
does not protect from a compromised kernel. This gives SGX a distinct advantage for securing portions of an application.
SEV however is specifically designed to allow the firmware environment necessary to allow the guest OS, and Hypervisor to see, and negotiate encryption of a Virtual Machine. This gives a (mostly) singular environment for a Virtual Machine to run in. For additional security, SME can be layered on top of SEV (which is already leveraging SME), to provide an an execution environment for applications running in a guest leveraging SME.
SGX would require a substantial amount of work to have similar functionality because
SGX does not provide this Hypervisor / OS middleware because the security engine resides on the CPU. The Hypervisor itself would have to be designed to access the secure enclaves, while providing appropriate security with nested "child" enclaves to move data about. It would also have to negotiate data in and out of the hardened enclaves and out of the host itself, which is a much more difficult task compared to the already known data of a specific application operation. The other alternative is to emulate SGX instructions in the Hypervisor, and use that to shuttle it to the CPU. This not only requires resource intensive binary translation, but is a massive engineering effort.
SGX is not designed for this.
SEV is providing functionality that Intel is not providing in SGX, just like SGX is providing functionality that neither SME nor SEV are providing.
Intel does not have a practical alternative to SEV at this time. That doesn't mean they won't be one, as I said in my original post to this thread. They could do SGX-v, or any kind of nomenclature that adds a middleware for Hypervisor awareness, but right now it is not there.
They are not the same thing.
But seriously, proof is in the pudding. Intel has had this product on the market and known for over a year now. Can you find any data whatsoever from Intel, showing SGX being leveraged to isolate virtual machines from each other? Something that is not a blog of someone's "well it could do this", but an actual paper, article, or summary from Intel that this could be practically implemented? Because I have found none. If you can provide one from Intel, I'd genuinely enjoy reading it. I'd like to know how they would implement it so I can see what I've missed.
Intel has had several papers, and videos on the subject, even one released a few days ago. Can you find anything that shows more than just specific application data being protected?