Will SME, SEV, and hw SHA be CPU game-changers?

Page 2 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

Rifter

Lifer
Oct 9, 1999
11,522
751
126
How about reading footnotes for once?




I was referencing my own stubborness first, bud.

All you need for intel AMT to work is a compatible chipset(which they are all post SB) be using intel GPU, and intel NIC. it must also be configured in the bios. For those of us that build our own PC's this is unlikely to effect us, but we are the vast minority. For those that use pre assembled dell, HP, insert OEM here laptops/computers(the vast majority) this is more of an issue as most of them have this enabled by default to aid in tech support. And some OEM's even remove the ability for the user to adjust AMT settings by changing the default bios password and not allowing end users to change intel AMT settings.
 

lolfail9001

Golden Member
Sep 9, 2016
1,056
353
96
Shifting goal posts, the expected tactic.
More like reduction of your argument to absurd, to disprove the thesis. Standard practice. So, try again to prove you belong in "Mass" when it comes to computers.

All you need for intel AMT to work is a compatible chipset(which they are all post SB) be using intel GPU, and intel NIC. it must also be configured in the bios. For those of us that build our own PC's this is unlikely to effect us, but we are the vast minority. For those that use pre assembled dell, HP, insert OEM here laptops/computers(the vast majority) this is more of an issue as most of them have this enabled by default to aid in tech support. And some OEM's even remove the ability for the user to adjust AMT settings by changing the default bios password and not allowing end users to change intel AMT settings.
That's a far cry from built-in 3G modem tho, as you see.
 

superstition

Platinum Member
Feb 2, 2008
2,219
221
101
More like reduction of your argument to absurd, to disprove the thesis. Standard practice.
Trolling may be standard practice for someone calling himself "lolfail" and bragging about being obnoxious but it's not actually logic. Another standard practice I have is of disengaging myself from stuff that pollutes the board so this is my last response to you here.
 
  • Like
Reactions: kraatus77

thecoolnessrune

Diamond Member
Jun 8, 2005
9,670
571
126
No game changer here, just keeping up with Intel.

This is not really true. Both are trying for the goal of "secured virtualization", but they are taking very different methods to get there, and the end result is also very different in the context of the goal.

Intel's SGX technology is more like a "container". When you create a secure virtual machine, Intel takes the route of creating what they term an "enclave" where all data or code is stored as part of that machine. Specific entry points are set up at the time of enclave creation. The encryption / decryption engine takes place entirely in the CPU, so even a completely compromised host cannot see the code. However, the overhead to do this appears to be high, as SGX is being aimed at protecting small ranges of memory, not entire VMs. You can make large enclaves, but you'll need to do some extra work to keep from taking too much memory away from the OS.

The major issue with the technology, aside from the size, is the key itself for the enclave. Creating an enclave requires a hash of the enclave data and a signature. The Signature needed to create an enclave is only accepted from Intel right now. You submit your hash, agree to terms and conditions, and get a signature in return. That's a problem from both a compliance issue and a security issue. The lack of openness regarding it has also meant that SGX patches are very slow in coming to the Linux kernel.

AMD's SME is simply setting an encryption key at power on to encrypt the data. This implementation is fairly simple, and the performance impact is considered to be only a little extra memory latency. However, SME on its own does not protect the data from a compromised kernel. SEV adds the ability for Individual VMs to be encrypted with their own key, but this still not prevent an attack via a compromised kernel.

AMD is essentially working towards an OS / VM level encryption (encrypt a whole VM or container), while Intel is working towards application level encryption (encrypt the memory space where a private key is being stored).

There is some crossover in functionality, but they are aiming at 2 entirely different philosophies of encryption of virtualized spaces.

Saying this is just AMD keeping up with Intel isn't accurate given the technologies involved.
 

Phynaz

Lifer
Mar 13, 2006
10,140
819
126
Thanks for write up on the different approaches.

One correction though, you can use self-signed certs with SGX. Intel even provides instructions on how to generate them using OpenSSL. The nice thing about having Intel be a steward of the certs is they can revoke them if there's an issue. Just like Google, Microsoft, et al have revoked certs in the past.

Regardless, from an end-user perspective, it is AMD keeping up with Intel. It adds security functionality to AMD CPU's that Intel has had for a while in their CPU's.
 
Last edited:

thecoolnessrune

Diamond Member
Jun 8, 2005
9,670
571
126
Thanks for write up on the different approaches.

One correction though, you can use self-signed certs with SGX. Intel even provides instructions on how to generate them using OpenSSL. The nice thing about having Intel be a steward of the certs is they can revoke them if there's an issue. Just like Google, Microsoft, et al have revoked certs in the past.

You are indeed correct. They are now allowing this to be done. There is still a massive roadblock in the fact that any commercial use application must be approved and on-boarded by Intel, but allowing certs outside Intel's to create enclaves is large compliance roadblock that is removed.

Regardless, from an end-user perspective, it is AMD keeping up with Intel. It adds security functionality to AMD CPU's that Intel has had for a while in their CPU's.

This just isn't true. It's very obvious that Intel SGX and AMD SME are both trying to tackle similar issues for application encryption. Intel states numerous times in their documentation that this is for applications. In fact, the only people mentioning it for Virtualization that I have seen have been bloggers. SGX is an micro-application security technology. It's meant to protect specific, encrypted areas of memory, and as I already posted above, it isn't being sold for anything that protected application areas.

SGX is Hardware-Assisted DRM. That's the best way to view its use cases. It's going to be used to protect key pieces of software from visibility, whether or not that's from the end user, or from people who are trying to compromise a system. It's DRM at it's core.

SME from AMD is largely the same thing, but SEV is something entirely different because it extends SME entirely around the idea of encapsulating Virtual Machines, with specific keys for each VM enclosure or portion of a VM, as well as extension support for Hypervisors to work with standard VM processes leveraging this encryption methodology.

SEV is Hardware-Assisted VM Encryption.

As far as I am aware, Intel has nothing like SEV currently released. Intel TXT or AMD TrustZone is not it. Intel SGX and AMD SME is not it.

Maybe I missed something, but I haven't seen anything that is a Virtualization purposed encryption extension.

You can say all day that SME is just AMD playing catch-up. But AMD SEV is simply not.

"From an end-user perspective" does not apply, as the application of AMD SEV is beyond what we would consider a layman would have any investment in. Just because your casual enthusiast does not understand the difference does not suddenly mean they are equivalent. SEV fulfills a very different purpose from SGX, and it will be up to AMD to make sure that those invested in it (Hypervisor developers, and IT Professionals) are properly made aware (via all those IT marketing dollars I see dropped around every day). The casual end user or enthusiast likely will have no interest in AMD SEV. Just like how there is a massive difference between VT-x and VT-d. The fact that enthusiasts twisted them together into the same thing means nothing towards the fact they suit very different purposes.
 
  • Like
Reactions: superstition

Phynaz

Lifer
Mar 13, 2006
10,140
819
126
You seem to have a fundamental misunderstanding of what SGX is. You keep using the word encryption, but that is only part of the picture. SGX is used to provide a trusted execution platform. The same thing AMD is doing.

Encryption by itself doesn't provide security in a computer system.
 

thecoolnessrune

Diamond Member
Jun 8, 2005
9,670
571
126
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?

 
  • Like
Reactions: superstition