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 <erdemak...@google.com> > Sent: Friday, April 16, 2021 3:43 AM > To: Paolo Bonzini <pbonz...@redhat.com> > Cc: devel@edk2.groups.io; j...@linux.ibm.com; Yao, Jiewen > <jiewen....@intel.com>; dgilb...@redhat.com; Laszlo Ersek > <ler...@redhat.com>; Xu, Min M <min.m...@intel.com>; > thomas.lenda...@amd.com; Brijesh Singh <brijesh.si...@amd.com>; Justen, > Jordan L <jordan.l.jus...@intel.com>; Ard Biesheuvel > <ardb+tianoc...@kernel.org>; Nathaniel McCallum > <npmccal...@redhat.com>; Ning Yang <ningy...@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 <pbonz...@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 > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#74314): https://edk2.groups.io/g/devel/message/74314 Mute This Topic: https://groups.io/mt/81969494/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
