| Message ID | 2f98be192cf6ffd36b984266570ea2eed4dfe364.1709044754.git.roy.hopkins@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Introduce support for IGVM files | expand |
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 ? 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. With regards, Daniel
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
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
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
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
diff --git a/docs/system/igvm.rst b/docs/system/igvm.rst new file mode 100644 index 0000000000..bb0c43f0ee --- /dev/null +++ b/docs/system/igvm.rst @@ -0,0 +1,58 @@ +Independent Guest Virtual Machine (IGVM) support +================================================ + +IGVM files are designed to encaspulate all the information required to launch a +virtual machine on any given virtualization stack in a deterministic way. This +allows the cryptographic measurement of initial guest state for Confidential +Guests to be calculated when the IGVM file is built, allowing a relying party to +verify the initial state of a guest via a remote attestation. + +QEMU supports IGVM files through the Confidential Guest Support object. An igvm +filename can optionally be passed to the object which will subsequently be +parsed and used to configure the guest state prior to launching the guest. + +Further Information on IGVM +--------------------------- + +Information about the IGVM format, including links to the format specification +and documentation for the Rust and C libraries can be found at the project +repository: + +https://github.com/microsoft/igvm + + +Supported Confidential Guests +----------------------------- + +Currently, IGVM files can be provided for Confidential Guests on host systems +that support AMD SEV and SEV-ES. + +IGVM files contain a set of directives. Not every directive is supported by +every Confidential Guest type. For example, setting the initial CPU state is not +supported on AMD SEV due to the platform not supporting encrypted save state +regions. However, this is supported on SEV-ES. + +When an IGVM file contains directives that are not supported for the active +platform, an error is displayed and the guest launch is aborted. + +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. + +Running a Confidential Guest configured using IGVM +-------------------------------------------------- + +To run a confidential guest configured with IGVM you need to add the +``igvm-file`` parameter to the "confidential guest support" object: + +Example (for AMD SEV):: + + qemu-system-x86_64 \ + <other parameters> \ + -machine ...,confidential-guest-support=sev0 \ + -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1,igvm-file=/path/to/guest.igvm diff --git a/docs/system/index.rst b/docs/system/index.rst index c21065e519..6235dfab87 100644 --- a/docs/system/index.rst +++ b/docs/system/index.rst @@ -38,4 +38,5 @@ or Hypervisor.Framework. security multi-process confidential-guest-support + igvm vm-templating
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