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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Mar 20, 2024 at 03:45:24PM +0000, Roy Hopkins wrote:
> 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?

Probably little more than change docs/interop/firmware.json
to add 'igvm' as a FirmwareDevice option to indicate this is
a new way of exposing it to the guest.

At some point we might also want to expand FirmwareFeature
eg to report a "vtpm" feature.


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

Sounds good.

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