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

[Roy Hopkins]

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.


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

> 
> With regards,
> Daniel

[1] COCONUT IGVM builder:
https://github.com/coconut-svsm/svsm/tree/main/igvmbuilder

Regards,
Roy