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/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.

SEV is atm considered 'secure' SGX is not:

https://arstechnica.com/information-technology/2020/03/hacke...

Not at all. SEV has been broken many times and by more trivial means [1-3]

[1] https://arxiv.org/pdf/1805.09604.pdf

[2] https://regmedia.co.uk/2019/07/10/amd.pdf

[3] https://www.theregister.com/2019/06/26/amd_epyc_key_security...

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