public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "James Bottomley" <jejb@linux.ibm.com>
To: Michael Brown <mcb30@ipxe.org>,
	devel@edk2.groups.io, lersek@redhat.com, "Yao,
	Jiewen" <jiewen.yao@intel.com>,
	"rfc@edk2.groups.io" <rfc@edk2.groups.io>
Cc: Brijesh Singh <brijesh.singh@amd.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	"erdemaktas@google.com" <erdemaktas@google.com>,
	"cho@microsoft.com" <cho@microsoft.com>,
	"bret.barkelew@microsoft.com" <bret.barkelew@microsoft.com>,
	Jon Lange <jlange@microsoft.com>, Karen Noel <knoel@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Nathaniel McCallum <npmccallum@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Ademar de Souza Reis Jr." <areis@redhat.com>
Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF
Date: Fri, 04 Jun 2021 08:04:16 -0700	[thread overview]
Message-ID: <3014a3275fa2a99de4fb34ca81f45d27b1bcd802.camel@linux.ibm.com> (raw)
In-Reply-To: <ec0a7879-b47f-90a4-042c-5747d38930f1@ipxe.org>

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



  reply	other threads:[~2021-06-04 15:04 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-03 13:51 [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF Yao, Jiewen
2021-06-03 16:11 ` Laszlo Ersek
2021-06-03 23:19   ` Yao, Jiewen
2021-06-04 10:11     ` Laszlo Ersek
2021-06-04 10:24       ` Yao, Jiewen
2021-06-04 10:43       ` Michael Brown
2021-06-04 14:52         ` Michael Brown
2021-06-04 15:04           ` James Bottomley [this message]
2021-06-04  7:33   ` Min Xu
2021-06-06  2:03   ` Min Xu
2021-06-06 11:29     ` Michael Brown
2021-06-06 12:49       ` Min Xu
2021-06-07 13:52         ` Laszlo Ersek
2021-06-06  8:52   ` Min Xu
2021-06-06 11:39     ` Michael Brown
2021-06-08 12:27   ` Min Xu
2021-06-08 15:36     ` Laszlo Ersek
2021-06-08 16:01 ` James Bottomley
2021-06-08 19:33   ` Laszlo Ersek
2021-06-09  0:58     ` Min Xu
2021-06-09 11:00       ` Laszlo Ersek
2021-06-09 14:36         ` James Bottomley
2021-06-09  2:01   ` Min Xu
2021-06-09 14:28     ` James Bottomley
2021-06-09 15:47       ` Paolo Bonzini
2021-06-09 15:59         ` James Bottomley
2021-06-10 21:01           ` Erdem Aktas
2021-06-10 22:30 ` Min Xu
2021-06-11  1:33   ` James Bottomley
2021-06-11  1:36     ` Yao, Jiewen
2021-06-11  1:38       ` James Bottomley
2021-06-11  1:55         ` James Bottomley
     [not found] ` <168759329436FBCF.5845@groups.io>
2021-06-11  6:37   ` Min Xu
2021-06-22 13:34     ` Laszlo Ersek
2021-06-22 13:38       ` Laszlo Ersek
2021-06-24  0:24         ` Min Xu
2021-06-24  0:35           ` James Bottomley
2021-06-24  0:55             ` Min Xu
     [not found]             ` <168B5EA81BA66FAC.7570@groups.io>
2021-07-01  5:00               ` Min Xu
2021-06-23  2:44       ` Min Xu
2021-06-23 17:47         ` Laszlo Ersek
2021-06-23 11:56       ` Min Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3014a3275fa2a99de4fb34ca81f45d27b1bcd802.camel@linux.ibm.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox