Re: [PATCH 9/9] docs/system: Add documentation on support for IGVM

[Roy Hopkins <roy.hopkins@suse.com>]

On Mon, 2024-03-18 at 16:21 +0000, Daniel P. Berrangé wrote:
> On Mon, Mar 18, 2024 at 03:59:31PM +0000, Roy Hopkins wrote:
> > On Fri, 2024-03-01 at 17:10 +0000, Daniel P. Berrangé wrote:
> > > On Tue, Feb 27, 2024 at 02:50:15PM +0000, Roy Hopkins wrote:
> > > > IGVM support has been implemented for Confidential Guests that support
> > > > AMD SEV and AMD SEV-ES. Add some documentation that gives some
> > > > background on the IGVM format and how to use it to configure a
> > > > confidential guest.
> > > > 
> > > > Signed-off-by: Roy Hopkins <roy.hopkins@suse.com>
> > > > ---
> > > >  docs/system/igvm.rst  | 58 +++++++++++++++++++++++++++++++++++++++++++
> > > >  docs/system/index.rst |  1 +
> > > >  2 files changed, 59 insertions(+)
> > > >  create mode 100644 docs/system/igvm.rst
> > > 
> > > 
> > > > +Firmware Images with IGVM
> > > > +-------------------------
> > > > +
> > > > +When an IGVM filename is specified for a Confidential Guest Support
> > > > object
> > > > it
> > > > +overrides the default handling of system firmware: the firmware image,
> > > > such
> > > > as
> > > > +an OVMF binary should be contained as a payload of the IGVM file and
> > > > not
> > > > +provided as a flash drive. The default QEMU firmware is not
> > > > automatically
> > > > mapped
> > > > +into guest memory.
> > > 
> > > IIUC, in future the IGVM file could contain both the OVMF and SVSM
> > > binaries ?
> > > 
> > > I'm also wondering if there can be dependancies between the IGVM
> > > file and the broader QEMU configuration ?  eg if SVSM gains suupport
> > > for data persistence, potentially we might need some pflash device
> > > exposed as storage for SVSM to use. Would such a dependancy be
> > > something expressed in the IGVM file, or would it be knowledge that
> > > is out of band ?
> > > 
> > Yes, the IGVM file can indeed contain both OVMF and SVSM binaries. In fact,
> > that
> > is exactly what we are doing with the COCONUT-SVSM project. See [1] for the
> > IGVM
> > builder we use to package OVMF, bootloader components and the SVSM ELF
> > binary.
> > 
> > Data persistence is something that is definitely going to be needed in the
> > SVSM.
> > At present, this cannot be configured using any of the directives in the
> > IGVM
> > specification but instead requires QEMU to be configured correctly to
> > support
> > the application embedded within the IGVM file itself. You could however
> > populate
> > metadata pages using IGVM that describe the storage that is _expected_ to be
> > present, and validate that within the firmware itself. 
> > 
> > The real value from IGVM comes from the ability to describe the initial
> > memory
> > and initial CPU state which all forms part of the launch measurement and
> > initial
> > boot procedure, allowing the expected launch measurement to be calculated
> > from a
> > single IGVM file for multiple virtualisation stacks or configurations. Thus,
> > most of the directives in the IGVM file directly have an effect on the
> > launch
> > measurement. I'm not sure configuring a storage device or other hardware
> > configuration fits well with this.
> 
> Yeah, I can understand if IGVM scope should be limited to just memory
> and CPU setup.
> 
> If we use the firmeware descriptor files, we could define capabilities
> in that to express a need for a particular type of persistent storage
> to back the vTPM. So having this info in IGVM files isn't critical.

I'll need to look into firmware descriptor files as I'm unfamiliar with how they
work. Would I need to make any additions to this patch series to support this in
QEMU? Or is this all handled by libvirt?

> 
> > > Finally, if we think of the IGVM file as simply yet another firmware
> > > file format, then it raises of question of integration into the
> > > QEMU firmware descriptors.
> > > 
> > > Right now when defining a guest in libvirt if you can say 'type=bios'
> > > or 'type=uefi', and libvirt consults the firmware descriptors to find
> > > the binary to use.
> > > 
> > > If the OS distro provides IGVM files instead of traditional raw OVMF
> > > binaries for SEV/TDX/etc, then from libvirt's POV I think having this
> > > expressed in the firmware descriptors is highly desirable.
> > > 
> > 
> > Whether IGVM is just another firmware file format or not, it certainly is
> > used
> > mutually exclusively with other firmware files. Integration with firmware
> > descriptors does seem to make sense. 
> > 
> > One further question if this is the case, would we want to switch from
> > specifying an "igvm-file" as a parameter on the "ConfidentialGuestSupport"
> > object to providing the file using the "-bios" parameter, or maybe even a
> > dedicated "-igvm" parameter?
> 
> If the IGVM format is flexible enough that it could be used for any VM
> type, even non-confidential VMs, then having its config be separate from
> ConfidentialGuestSUpport would make sense. If it is fundamentally tied
> to CVMs, then just a property is fine I guess.
> 
> Probably best to stay away from -bios, to avoid overloading new semantics
> onto a long standing argument.
> 
> With regards,
> Daniel

Currently, the IGVM specification only contains support for confidential
platforms. It could theoretically be used for non-confidential platforms but
that would require changes to the IGVM specification itself to support this. I
don't think it makes sense to extend this to non-confidential VMs until the
specification supports this, so I'll leave it as a property of
ConfidentialGuestSupport.


Regards,
Roy