6 ms·

> Is SEV really a "breakthrough technology"? SEV is a breakthrough in the sense that it's essentially transparent to the guest environment. Earlier technologie

> Is SEV really a "breakthrough technology"? SEV is a breakthrough in the sense that it's essentially transparent to the guest environment. Earlier technologies like Intel SGX or ARM TrustZone have a lot of performance limitations, and application needs to be explicitly developed to support it. Intel is working on a similar technology -- Total Memory Encryption (TME) -- but they haven't released it to market yet.

thu2111 6y ago
Intel actually had a similar tech without the RAM encryption some time ago, called TXT. TXT never really took off. There were a few problems, but, I don't think SEV has actually solved these problems, beyond the lack of the memory encryption. One is that the hypervisor is ... well it's still a hypervisor. It can play a lot of games on the operating system, and hardware is limited in what it can do to stop that. TXT's solution was to "measure" the hypervisor, so you could audit it. That doesn't work for google/aws/azure who all use proprietary hypervisors, so you need to place a lot of trust in your chip and kernel that they can resist arbitrary malicious behaviour by the most privileged piece of software on the system - one that controls all hardware access. That's very difficult. For instance, the hypervisor controls access to the system clock. Another is that it was very hard to make the operating system secure. Heartbleed being just one example of what can go wrong. So the trusted computing community concluded around this time that placing an entire operating system into your 'trusted computing base' doesn't really work. It's trying to run before you can walk. If you can't make the operating system reliably secure against remote attackers then trying to make it secure against the far harder adversary of someone who controls your hardware stack seems futile. That's why Intel's equivalent isn't transparent. It's not very opaque, it's basically like loading a shared library and the library gets encrypted RAM. But when you try to write an enclave that's really secure, you realise that there's a lot the host machine can do to make a mess of things. I don't think that changes much if it's "just" the hypervisor that's malicious instead of the hypervisor and kernel. The solutions end up looking the same - you want to minimise your attack surface, you need to think carefully about clocks and time sequencing, side channel attacks, etc.
- theevilsharpie 6y ago
  > Intel actually had a similar tech without the RAM encryption some time ago, called TXT. Given that RAM encryption is literally the core function of SEV, any functionality that lacks it is by definition dissimilar.
  - thu2111 6y ago
    TXT had RAM protection, as in, other software or hardware devices couldn't read the protected memory areas. RAM encryption itself is primarily about stopping bus sniffing or cold boot attacks. Useful, but by no means the only kind of protection you need. Especially because combining encryption with authentication is very hard. It is easy to forget that encryption doesn't stop someone flipping bits and you can corrupt the plaintext in ways useful to an attacker by doing so, hence the rise of AES/GCM. But I don't think SEV uses AEAD? But the core technology is basically the same concept. You get a protected memory space (to some degree of protection), you can derive keys linked to the loaded code hash, and you can do remote attestation to set up a Diffie-Hellman handshake with the remote protected domain. All that stuff is identical between TXT and SEV.

thu2111 6y ago

Intel actually had a similar tech without the RAM encryption some time ago, called TXT. TXT never really took off. There were a few problems, but, I don't think SEV has actually solved these problems, beyond the lack of the memory encryption. One is that the hypervisor is ... well it's still a hypervisor. It can play a lot of games on the operating system, and hardware is limited in what it can do to stop that. TXT's solution was to "measure" the hypervisor, so you could audit it. That doesn't work for google/aws/azure who all use proprietary hypervisors, so you need to place a lot of trust in your chip and kernel that they can resist arbitrary malicious behaviour by the most privileged piece of software on the system - one that controls all hardware access. That's very difficult. For instance, the hypervisor controls access to the system clock. Another is that it was very hard to make the operating system secure. Heartbleed being just one example of what can go wrong. So the trusted computing community concluded around this time that placing an entire operating system into your 'trusted computing base' doesn't really work. It's trying to run before you can walk. If you can't make the operating system reliably secure against remote attackers then trying to make it secure against the far harder adversary of someone who controls your hardware stack seems futile. That's why Intel's equivalent isn't transparent. It's not very opaque, it's basically like loading a shared library and the library gets encrypted RAM. But when you try to write an enclave that's really secure, you realise that there's a lot the host machine can do to make a mess of things. I don't think that changes much if it's "just" the hypervisor that's malicious instead of the hypervisor and kernel. The solutions end up looking the same - you want to minimise your attack surface, you need to think carefully about clocks and time sequencing, side channel attacks, etc.

theevilsharpie 6y ago
> Intel actually had a similar tech without the RAM encryption some time ago, called TXT. Given that RAM encryption is literally the core function of SEV, any functionality that lacks it is by definition dissimilar.
- thu2111 6y ago
  TXT had RAM protection, as in, other software or hardware devices couldn't read the protected memory areas. RAM encryption itself is primarily about stopping bus sniffing or cold boot attacks. Useful, but by no means the only kind of protection you need. Especially because combining encryption with authentication is very hard. It is easy to forget that encryption doesn't stop someone flipping bits and you can corrupt the plaintext in ways useful to an attacker by doing so, hence the rise of AES/GCM. But I don't think SEV uses AEAD? But the core technology is basically the same concept. You get a protected memory space (to some degree of protection), you can derive keys linked to the loaded code hash, and you can do remote attestation to set up a Diffie-Hellman handshake with the remote protected domain. All that stuff is identical between TXT and SEV.