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

Yao, Jiewen jiewen.yao at intel.com
Mon Apr 12 11:54:38 UTC 2021


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 at edk2.groups.io <devel at edk2.groups.io> On Behalf Of Dr. David
> Alan Gilbert
> Sent: Monday, April 12, 2021 4:35 PM
> To: Laszlo Ersek <lersek at redhat.com>
> Cc: Yao, Jiewen <jiewen.yao at intel.com>; Xu, Min M <min.m.xu at intel.com>;
> devel at edk2.groups.io; thomas.lendacky at amd.com; jejb at linux.ibm.com;
> Brijesh Singh <brijesh.singh at amd.com>; Justen, Jordan L
> <jordan.l.justen at intel.com>; Ard Biesheuvel <ardb+tianocore at kernel.org>;
> Paolo Bonzini <pbonzini at redhat.com>; Nathaniel McCallum
> <npmccallum at 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 at 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 at redhat.com / Manchester, UK
> 
> 
> 
> 
> 



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






More information about the edk2-devel-archive mailing list