[libvirt PATCH 1/5] docs: explain that some UEFI images can use 'rom' instead of 'pflash'

[Erik Skultety]

On Fri, Jan 14, 2022 at 07:07:11PM +0000, Daniel P. Berrangé wrote:
> The normal requirements for UEFI firmware images are to support
> persistence of variables, either in the main image, or more typically in
> a separate NVRAM file.
> 
> In a confidential computing environment, however, persistence of
> variables can cause trust issues and prevent measurement of the firmware
> during boot up. For these scenarios some UEFI images will disable
> persistence of variables. To use such images the loader type must be set
> to 'rom' instead of 'pflash'.
> 
> Signed-off-by: Daniel P. Berrangé <berrange at redhat.com>
> ---
>  docs/formatdomain.rst | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
> index c0b2d935f3..cd818c1ded 100644
> --- a/docs/formatdomain.rst
> +++ b/docs/formatdomain.rst
> @@ -214,10 +214,14 @@ harddisk, cdrom, network) determining where to obtain/find the boot image.
>     the fact that the image should be writable or read-only. The second attribute
>     ``type`` accepts values ``rom`` and ``pflash``. It tells the hypervisor where
>     in the guest memory the file should be mapped. For instance, if the loader
> -   path points to an UEFI image, ``type`` should be ``pflash``. Moreover, some
> -   firmwares may implement the Secure boot feature. Attribute ``secure`` can be
> -   used to tell the hypervisor that the firmware is capable of Secure Boot feature.
> -   It cannot be used to enable or disable the feature itself in the firmware.
> +   path points to an UEFI image, ``type`` would normally be ``pflash`` to
> +   enable support for persistence of firmware variables. Moreover, some
> +   firmwares may implement the Secure boot feature. Some UEFI images intended

^This Secure boot sentence should go after explaining why confidential
computing would prefer the type 'rom'

Reviewed-by: Erik Skultety <eskultet at redhat.com>

> +   for use with confidential computing environments like AMD SEV will disable
> +   persistence of variables, and would thus require ``type`` to be ``rom``.
> +   Attribute ``secure`` can be used to tell the hypervisor that the firmware
> +   is capable of Secure Boot feature. It cannot be used to enable or disable
> +   the feature itself in the firmware.
>     :since:`Since 2.1.0`
>  ``nvram``
>     Some UEFI firmwares may want to use a non-volatile memory to store some

> -- 
> 2.33.1
>