Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF

["James Bottomley" <jejb@linux.ibm.com>]

On Wed, 2021-06-09 at 17:47 +0200, Paolo Bonzini wrote:
> On 09/06/21 16:28, James Bottomley wrote:
> > That would cut across the ApEntrypoint and the guidedStructureEnd.
> > However, nothing says anything in the reset vector guided structure
> > has to be data ... so it could equally well be code.  That means we
> > can do guid based entries that contain the 32 bit real and 64 bit
> > entry points.  This would also come with the added advantage that
> > we can scan the OVMF binary to see what entry points it supports.
> 
> Isn't the initial state included in the save area just like for SEV-
> ES?

Initial state of what?  We currently have two entries: one points to
the address and size of the secrets page and the other gives the
address of the ES work area page that's used for AP reset.

>    So it's not even QEMU, but rather some external tool that builds
> the encrypted image, that needs to understand that GUIDed structure.

Yes, it's really to make the configuration of the OVMF blob somewhat
introspectable.  The current consumer is QEMU, but I see no reason why
other tools might not use this mechanism as well.

> The GUIDed structure can either include the entry point code; or it 
> could have room for a couple 8-byte pointers since any fixed-size
> area in the GUIDed structure would be just a jump anyway.

Well, exactly ... depending on what the requirement is we can do pretty
much anything with the data contents with the only caveat that it's
currently constructed by an asm file, so we don't quite have the full
macro power of C available.  However, symbol resolution is definitely
possible and quite easy.

James