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

[Daniel P . Berrangé]

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.

> > 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
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|