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>]

I totally agree with you that from security perspective, the best idea to isolate AMD SEV/Intel TDX from standard OVMF.

Do you want to propose move AMD SEV support to another SEC?

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Dr. David
> Alan Gilbert
> Sent: Monday, April 12, 2021 4:35 PM
> To: Laszlo Ersek <lersek@redhat.com>
> Cc: Yao, Jiewen <jiewen.yao@intel.com>; Xu, Min M <min.m.xu@intel.com>;
> devel@edk2.groups.io; thomas.lendacky@amd.com; jejb@linux.ibm.com;
> Brijesh Singh <brijesh.singh@amd.com>; Justen, Jordan L
> <jordan.l.justen@intel.com>; Ard Biesheuvel <ardb+tianocore@kernel.org>;
> Paolo Bonzini <pbonzini@redhat.com>; Nathaniel McCallum
> <npmccallum@redhat.com>
> Subject: Re: [edk2-devel] separate OVMF binary for TDX? [was: OvmfPkg:
> Reserve the Secrets and Cpuid page for the SEV-SNP guest]
> 
> * Laszlo Ersek (lersek@redhat.com) wrote:
> > On 04/09/21 15:44, Yao, Jiewen wrote:
> > > Hi Laszlo
> > > Thanks.
> > >
> > > We did provide a separate binary in the beginning - see
> https://github.com/tianocore/edk2-staging/tree/TDVF, with same goal - easy to
> maintain and develop. A clean solution, definitely.
> > >
> > > However, we got requirement to deliver one binary solution together with 1)
> normal OVMF, 2) AMD-SEV, 3) Intel-TDX.
> > > Now, we are struggling to merge them......
> > >
> > > For DXE, we hope to isolate TDX driver whenever it is possible.
> > > But we only have one reset vector here. Sigh...
> >
> > Can we please pry a little bit at that "one binary" requirement?
> >
> > Ultimately the "guest bundle" is going to be composed by much
> > higher-level code, I expect (such as some userspace code, written in
> > python or similar); selecting a firmware binary in such an environment
> > is surely easier than handling this "polymorphism" in the most
> > restrictive software environment imaginable (reset vector assembly code
> > in the guest)?
> 
> I think also there's a security argument here; some people like to
> measure security in kloc's; so having your secure boot image as small
> as possible for the environment you're actually running does make some
> sense, which favours the 2 image idea.
> 
> Dave
> 
> > Thanks
> > Laszlo
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> 
> 
> 
> 
>