Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF

James Bottomley

On Fri, 2021-06-04 at 15:52 +0100, Michael Brown wrote:
On 04/06/2021 11:43, Michael Brown wrote:
On 04/06/2021 11:11, Laszlo Ersek wrote:
And, to reiterate, just because Confidential Computing is the
new hot thing, the use cases for OvmfPkgIa32, OvmfPkgIa32X64,
OvmfPkgX64 do not disappear. Regressing them, or making them
unmaintainable due to skyrocketing complexity, is not acceptable.
Totally agree with this. Confidential Computing is a very niche
use case, and there is no justification for exploding the
complexity of the standard OVMF build.

If, several years from now, it ever reaches the point that the
majority of real-world workloads are using TDX, then there would be
an argument that the complexity cost has to be paid and that the
standard OVMF build should include TDX features. But that's
several years away and may never happen.
Out of interest: does Intel TDX provide any security benefits beyond
the (much simpler) Intel SGX?
The main benefit is ease of deployment for unmodified applications.
While you might argue this isn't a "security" benefit, remember that
any security technology that is too complex for most people to deploy
doesn't have much impact, so ease of use is a significant consideration
in security technologies.

As far as I can tell from the various papers, the fundamental
difference between TDX and SGX seems to be that TDX deliberately
increases the attack surface from "just the application code" to
"entire guest VM, including OS kernel, runtime libraries,
etc". Increasing the attack surface while adding complexity is a
huge cost so I'm assuming that there must be some commensurate
benefit, but nothing in the documentation I've seen seems to describe
what this benefit actually is.
The big problems of enclave technology like SGX is rewriting
applications into secure and insecure parts and controlling information
leak across the boundaries of the enclave ... even if you opt to run
the application entirely within the enclave, you still get leaks into
the kernel via syscalls and the machine owner still has a huge amount
of leeway to exfiltrate any secrets in the enclave.

The push towards VM based isolation is because all the handling of the
technology can be done inside an enlightened guest kernel (so any
application will run with no modification) and the guest to host
boundary is a far easier to analyse being a hardware emulation
vmexit/hypercall one rather than the huge and complex syscall


Join to automatically receive all group messages.