Re: [edk2-devel] separate OVMF binary for TDX? [was: OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest]

["Yao, Jiewen" <jiewen.yao@intel.com>]

Hello 
Do we have some conclusion on this topic?

Do we agree the one-binary solution in OVMF or we need more discussion?


Thank you
Yao Jiewen

> -----Original Message-----
> From: Erdem Aktas <erdemaktas@google.com>
> Sent: Friday, April 16, 2021 3:43 AM
> To: Paolo Bonzini <pbonzini@redhat.com>
> Cc: devel@edk2.groups.io; jejb@linux.ibm.com; Yao, Jiewen
> <jiewen.yao@intel.com>; dgilbert@redhat.com; Laszlo Ersek
> <lersek@redhat.com>; Xu, Min M <min.m.xu@intel.com>;
> thomas.lendacky@amd.com; Brijesh Singh <brijesh.singh@amd.com>; Justen,
> Jordan L <jordan.l.justen@intel.com>; Ard Biesheuvel
> <ardb+tianocore@kernel.org>; Nathaniel McCallum
> <npmccallum@redhat.com>; Ning Yang <ningyang@google.com>
> Subject: Re: [edk2-devel] separate OVMF binary for TDX? [was: OvmfPkg:
> Reserve the Secrets and Cpuid page for the SEV-SNP guest]
> 
> Thanks Paolo.
> 
> On Thu, Apr 15, 2021 at 12:59 AM Paolo Bonzini <pbonzini@redhat.com>
> wrote:
> >
> > On 15/04/21 01:34, Erdem Aktas wrote:
> > > We do not want to generate different binaries for AMD, Intel, Intel
> > > with TDX, AMD with SEV/SNP etc
> >
> > My question is why the user would want a single binary for VMs with and
> > without TDX/SNP.  I know there is attestation, but why would you even
> > want the _possibility_ that your guest starts running without TDX or SNP
> > protection, and only find out later via attestation?
> 
> There might be multiple reasons why customers want it but we need this
> requirement for a couple of other reasons too.
> 
> We do not only have hardware based confidential VMs. We might have
> some other solutions which measure the initial image before boot.
> Ultimately we might want to use a common attestation interface where
> customers might be running different kinds of VMs. Using a single
> binary will make it easier to manage/verify measurements for both of
> us and the customers. I am not a PM so I cannot give more context on
> customer use cases.
> 
> Another reason is how we deploy and manage guest firmware. We have a
> lot of optimization and customization to speed up firmware loading
> time and also reduce the time to deploy new builds on the whole fleet
> uniformly.  Adding a new firmware binary is a big challenge for us to
> enable these features. On the top of integration challenges, it will
> create maintainability issues in the long run for us when we provide
> tools to verify/reproduce the hashes in the attestation report.
> 
> > want the _possibility_ that your guest starts running without TDX or SNP
> > protection, and only find out later via attestation?
> 
> I am missing the point here. Customers should rely on only the
> attestation report to establish the trust.
> -If firmware does not support TDX and TDX is enabled, that firmware
> will crash at some point.
> -If firmware is generic firmware that supports TDX and SNP and others,
> and TDX is enabled or not,  still the customer needs to verify the TDX
> enablement through attestation.
> -If firmware is a customized binary compiled to support TDX,
> irrelevant of TDX being enabled or not,  still the customer needs to
> verify the TDX enablement through attestation.
> 
> 
> > For a similar reason, OVMF already supports shipping a binary that fails
> > to boot if SMM is not available to the firmware, because then secure
> > boot would be trivially circumvented.
> >
> > I can understand having a single binary for both TDX or SNP.  That's not
> > a problem since you can set up the SEV startup VMSA to 32-bit protected
> > mode just like TDX wants.
> 
> I agree that this is doable but I am not sure if we need to also
> modify the reset vector for AMD SNP in that case. Also it will not
> solve our problem. If we start to generate a new firmware for every
> feature , it will not end well for us, I think. Both TDX and SNP are
> still new features in the same architecture, and it seems to me that
> they are sharing a lot of common/similar code. AMD has already made
> some of their patches in (SEV and SEV-ES) which works very nicely for
> our use case and integration. Looks like Intel just has an issue on
> how to fix their reset vector problem. Once they solve it and upstream
> accepts the changes, I do not see any other big blocker. OVMF was
> doing a great job on abstracting differences and providing a common
> interface without creating multiple binaries. I do not see why it
> should not do the same thing here.
> 
> > > therefore we were expecting the TDX
> > > changes to be part of the upstream code.
> >
> > Having 1 or more binaries should be unrelated to the changes being
> > upstream (or more likely, I am misunderstanding you).
> 
> You are right, it is my bad for not clarifying it. What I mean is we
> want it to be part of the upstream so it can be easier for us to pull
> the changes and they are compatible with the changes that SNP is doing
> but we also do not want to use different configuration files to
> generate different binaries for each use case.
> 
> 
> > Thanks,
> >
> > Paolo
> >