[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
interface.

James




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#76080): https://edk2.groups.io/g/devel/message/76080
Mute This Topic: https://groups.io/mt/83283616/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-