5 ms·

How is SEV compared to SGX?

• nix23 6y ago
  SEV is atm considered 'secure' SGX is not: https://arstechnica.com/information-technology/2020/03/hackers-can-steal-secret-data-stored-in-intels-sgx-secure-enclave/ https://arstechnica.com/information-technology/2020/03/hacke...
  • als0 6y ago
    Not at all. SEV has been broken many times and by more trivial means [1-3] [1] https://arxiv.org/pdf/1805.09604.pdf https://arxiv.org/pdf/1805.09604.pdf [2] https://regmedia.co.uk/2019/07/10/amd.pdf https://regmedia.co.uk/2019/07/10/amd.pdf [3] https://www.theregister.com/2019/06/26/amd_epyc_key_security_flaw/ https://www.theregister.com/2019/06/26/amd_epyc_key_security...
    • benlivengood 6y ago
      The two attack vectors are page table integrity and unencrypted VM state. Modifying the page tables to establish a cryptographic merkle tree would fix the first attack, and SEV-ES fixes the secrecy attack from the second paper. Unfortunately a change to page table structure may make it impossible to run unmodified kernels in the VM. I think it as impossible to prevent a hypervisor from fingerprinting what's running on a child VM; there are too many timing and power attacks to ever mitigate that, which was the attack vector on SEV-ES
• nellydpa 6y ago
  SEV: No changes are required to the apps, better performance, but bigger TCB. GCP mitigate this with Shielded VMs, in particular integrity of the kernel in your trusted boundary, notifications to users if the integrity state changed from the baseline and made it default and free. https://cloud.google.com/blog/products/identity-security/security-simplified-making-shielded-vm-default-compute-engine https://cloud.google.com/blog/products/identity-security/sec... SGX: smaller TCB, but limited scale, and you have to partition your app to secure and no-secure parts using one of the SDK available, Intel SGX SDK, Microsoft OpenEnclave or Google Asylo.