mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-07-12 12:55:46 +00:00
85a4f035f6
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
667 lines
22 KiB
ReStructuredText
667 lines
22 KiB
ReStructuredText
======================
|
|
virt-qemu-sev-validate
|
|
======================
|
|
|
|
--------------------------------------------
|
|
validate a domain AMD SEV launch measurement
|
|
--------------------------------------------
|
|
|
|
:Manual section: 1
|
|
:Manual group: Virtualization Support
|
|
|
|
.. contents::
|
|
|
|
SYNOPSIS
|
|
========
|
|
|
|
|
|
``virt-qemu-sev-validate`` [*OPTIONS*]
|
|
|
|
|
|
DESCRIPTION
|
|
===========
|
|
|
|
This program validates the reported measurement for a domain launched with AMD
|
|
SEV. If the program exits with a status of zero, the guest owner can be
|
|
confident that their guest OS is running under the protection offered by the
|
|
SEV / SEV-ES platform.
|
|
|
|
Note that the level of protection varies depending on the AMD SEV platform
|
|
generation and describing the differences is outside the scope of this
|
|
document.
|
|
|
|
For the results of this program to be considered trustworthy, it is required to
|
|
be run on a machine that is already trusted by the guest owner. This could be a
|
|
machine that the guest owner has direct physical control over, or it could be
|
|
another virtual machine protected by AMD SEV that has already had its launch
|
|
measurement validated. Running this program on the virtualization host will not
|
|
produce an answer that can be trusted.
|
|
|
|
If told to connect to libvirt, it will refuse to use a libvirt connection that
|
|
is local to the machine, since that cannot be trusted. For the sake of testing
|
|
or demonstration purposes, however, it can be forced to run in this scenario
|
|
using the ``--insecure`` flag. The result will, of course, still not be
|
|
trustworthy.
|
|
|
|
OPTIONS
|
|
=======
|
|
|
|
Common options
|
|
--------------
|
|
|
|
``-h``, ``--help``
|
|
|
|
Display command line help usage then exit.
|
|
|
|
``-d``, ``--debug``
|
|
|
|
Show debug information while running
|
|
|
|
``-q``, ``--quiet``
|
|
|
|
Don't print information about the attestation result.
|
|
|
|
Guest state options
|
|
-------------------
|
|
|
|
These options provide information about the state of the guest that needs its
|
|
boot attested.
|
|
|
|
``--measurement BASE64-STRING``
|
|
|
|
The launch measurement reported by the hypervisor of the domain to be validated.
|
|
The measurement must be 48 bytes of binary data encoded as a base64 string.
|
|
|
|
``--api-major VERSION``
|
|
|
|
The SEV API major version of the hypervisor the domain is running on.
|
|
|
|
``--api-minor VERSION``
|
|
|
|
The SEV API major version of the hypervisor the domain is running on.
|
|
|
|
``--build-id ID``
|
|
|
|
The SEV build ID of the hypervisor the domain is running on.
|
|
|
|
``--policy POLiCY``
|
|
|
|
The policy bitmask associated with the session launch data of the domain to be
|
|
validated.
|
|
|
|
Guest config options
|
|
--------------------
|
|
|
|
These options provide items needed to calculate the expected domain launch
|
|
measurement. This will then be compared to the reported launch measurement.
|
|
|
|
``-f PATH``, ``--firmware=PATH``
|
|
|
|
Path to the firmware loader binary. This is the EDK2 build that knows how to
|
|
initialize AMD SEV. For the validation to be trustworthy it important that the
|
|
firmware build used has no support for loading non-volatile variables from
|
|
NVRAM, even if NVRAM is expose to the guest.
|
|
|
|
``-k PATH``, ``--kernel=PATH``
|
|
|
|
Path to the kernel binary if doing direct kernel boot.
|
|
|
|
``-r PATH``, ``--initrd=PATH``
|
|
|
|
Path to the initrd binary if doing direct kernel boot. Defaults to zero length
|
|
content if omitted.
|
|
|
|
``-e STRING``, ``--cmdline=STRING``
|
|
|
|
String containing any kernel command line parameters used during boot of the
|
|
domain. Defaults to the empty string if omitted.
|
|
|
|
``-n COUNT``, ``--num-cpus=COUNT``
|
|
|
|
The number of virtual CPUs for the domain. This is required when the
|
|
domain policy is set to require SEV-ES.
|
|
|
|
``-0 PATH``, ``--vmsa-cpu0=PATH``
|
|
|
|
Path to the VMSA initial state for the boot CPU. This is required when
|
|
the domain policy is set to require SEV-ES. The file contents must be
|
|
exactly 4096 bytes in length.
|
|
|
|
``-1 PATH``, ``--vmsa-cpu1=PATH``
|
|
|
|
Path to the VMSA initial state for the non-boot CPU. This is required when
|
|
the domain policy is set to require SEV-ES and the domain has more than one
|
|
CPU present. The file contents must be exactly 4096 bytes in length.
|
|
|
|
``--tik PATH``
|
|
|
|
TIK file for domain. This file must be exactly 16 bytes in size and contains the
|
|
unique transport integrity key associated with the domain session launch data.
|
|
This is mutually exclusive with the ``--tk`` argument.
|
|
|
|
``--tek PATH``
|
|
|
|
TEK file for domain. This file must be exactly 16 bytes in size and contains the
|
|
unique transport encryption key associated with the domain session launch data.
|
|
This is mutually exclusive with the ``--tk`` argument.
|
|
|
|
``--tk PATH``
|
|
|
|
TEK/TIK combined file for the domain. This file must be exactly 32 bytes in
|
|
size, with the first 16 bytes containing the TEK and the last 16 bytes
|
|
containing the TIK. This is mutually exclusive with the ``--tik`` and ``--tek``
|
|
arguments.
|
|
|
|
Libvirt options
|
|
---------------
|
|
|
|
These options are used when connecting to libvirt to automatically obtain
|
|
state and configuration information about the domain to be attested.
|
|
|
|
``-c``, ``--connect URI``
|
|
|
|
Libvirt connection URI. For the validation to be trustworthy this must be a URI
|
|
resolving to a remote virtualization host. This requirement can be overridden
|
|
using the ``--insecure`` argument.
|
|
|
|
``-o``, ``--domain ID|NAME|UUID``
|
|
|
|
Domain ID, or domain name or domain UUID. Used to identify which libvirt domain
|
|
is to have its launch measured. The domain must be running, and would usually
|
|
have been started in a paused state, to allow validation to be performed before
|
|
guest CPUs begin execution.
|
|
|
|
``-i``, ``--insecure``
|
|
|
|
Proceed even if usage scenario is known to be insecure. This allows the program
|
|
to connect to a local libvirt hypervisor and rely on file content from the
|
|
virtualization host. It also allows the validation to proceed even if the
|
|
virtual machine CPUs are not in the initial paused state. The result of the
|
|
validation must not be trusted.
|
|
|
|
``-g``, ``--ignore-config``
|
|
|
|
Do not attempt to sanity check the domain config. The default behaviour is to
|
|
print out errors if identifying configuration elements in the guest XML that
|
|
would invalidate the launch measurement. This can help the guest owner to
|
|
understand any configuration mistakes that have been made. If the
|
|
``--ignore-config`` argument is given, this sanity checking of configuration
|
|
will be skipped. The result is that the validation will likely be reported as
|
|
failed.
|
|
|
|
Secret injection options
|
|
------------------------
|
|
|
|
These options provide a way to inject a secret if validation of the
|
|
launch measurement passes.
|
|
|
|
``--inject-secret ALIAS-OR-GUID:PATH``
|
|
|
|
Path to a file containing a secret to inject into the guest OS. Typical
|
|
usage would be to supply a password for unlocking the root filesystem
|
|
full disk encryption. ``ALIAS`` can be one of the well known secrets:
|
|
|
|
* ``luks-key`` - bytes to use as a key for unlocking a LUKS key slot.
|
|
GUID of ``736869e5-84f0-4973-92ec-06879ce3da0b``.
|
|
|
|
Alternatively ``GUID`` refers to an arbitrary UUID of the callers
|
|
choosing. The contents of ``PATH`` are defined by the requirements
|
|
of the associated GUID, and will used as-is without modification.
|
|
In particular be aware:
|
|
|
|
* Avoid unwanted trailing newline characters in ``PATH`` unless
|
|
mandated by the ``GUID``.
|
|
* Any trailing ``NUL`` byte must be explicitly included in ``PATH``
|
|
if mandated by the ``GUID``.
|
|
|
|
This argument can be repeated multiple times, provided a different
|
|
``GUID`` is given for each instance.
|
|
|
|
``--secret-header PATH``
|
|
|
|
Path to a file in which the injected secret header will be written in base64
|
|
format and later injected into the domain. This is required if there is no
|
|
connection to libvirt, otherwise the secret will be directly injected.
|
|
|
|
``--secret-payload PATH``
|
|
|
|
Path to a file in which the injected secret payload will be written in base64
|
|
format and later injected into the domain. This is required if there is no
|
|
connection to libvirt, otherwise the secret will be directly injected.
|
|
|
|
EXAMPLES
|
|
========
|
|
|
|
Fully offline execution
|
|
-----------------------
|
|
|
|
This scenario allows a measurement to be securely validated in a completely
|
|
offline state without any connection to the hypervisor host. All required
|
|
data items must be provided as command line parameters. This usage model is
|
|
considered secure, because all input data is provided by the user.
|
|
|
|
Validate the measurement of a SEV guest booting from disk:
|
|
|
|
::
|
|
|
|
# virt-qemu-sev-validate \
|
|
--firmware OVMF.sev.fd \
|
|
--tk this-guest-tk.bin \
|
|
--measurement Zs2pf19ubFSafpZ2WKkwquXvACx9Wt/BV+eJwQ/taO8jhyIj/F8swFrybR1fZ2ID \
|
|
--api-major 0 \
|
|
--api-minor 24 \
|
|
--build-id 13 \
|
|
--policy 3
|
|
|
|
Validate the measurement of a SEV guest with direct kernel boot:
|
|
|
|
::
|
|
|
|
# virt-qemu-sev-validate \
|
|
--firmware OVMF.sev.fd \
|
|
--kernel vmlinuz-5.11.12 \
|
|
--initrd initramfs-5.11.12 \
|
|
--cmdline "root=/dev/vda1" \
|
|
--tk this-guest-tk.bin \
|
|
--measurement Zs2pf19ubFSafpZ2WKkwquXvACx9Wt/BV+eJwQ/taO8jhyIj/F8swFrybR1fZ2ID \
|
|
--api-major 0 \
|
|
--api-minor 24 \
|
|
--build-id 13 \
|
|
--policy 3
|
|
|
|
Validate the measurement of a SEV-ES SMP guest booting from disk:
|
|
|
|
::
|
|
|
|
# virt-qemu-sev-validate \
|
|
--firmware OVMF.sev.fd \
|
|
--num-cpus 2 \
|
|
--vmsa-cpu0 vmsa0.bin \
|
|
--vmsa-cpu1 vmsa1.bin \
|
|
--tk this-guest-tk.bin \
|
|
--measurement Zs2pf19ubFSafpZ2WKkwquXvACx9Wt/BV+eJwQ/taO8jhyIj/F8swFrybR1fZ2ID \
|
|
--api-major 0 \
|
|
--api-minor 24 \
|
|
--build-id 13 \
|
|
--policy 7
|
|
|
|
Validate the measurement of a SEV-ES SMP guest booting from disk, with
|
|
automatically constructed VMSA:
|
|
|
|
::
|
|
|
|
# virt-qemu-sev-validate \
|
|
--firmware OVMF.sev.fd \
|
|
--num-cpus 2 \
|
|
--cpu-family 23 \
|
|
--cpu-model 49 \
|
|
--cpu-stepping 0 \
|
|
--tk this-guest-tk.bin \
|
|
--measurement Zs2pf19ubFSafpZ2WKkwquXvACx9Wt/BV+eJwQ/taO8jhyIj/F8swFrybR1fZ2ID \
|
|
--api-major 0 \
|
|
--api-minor 24 \
|
|
--build-id 13 \
|
|
--policy 7
|
|
|
|
Validate the measurement of a SEV guest booting from disk and
|
|
inject a disk password on success:
|
|
|
|
::
|
|
|
|
# virt-qemu-sev-validate \
|
|
--firmware OVMF.sev.fd \
|
|
--tk this-guest-tk.bin \
|
|
--measurement Zs2pf19ubFSafpZ2WKkwquXvACx9Wt/BV+eJwQ/taO8jhyIj/F8swFrybR1fZ2ID \
|
|
--api-major 0 \
|
|
--api-minor 24 \
|
|
--build-id 13 \
|
|
--policy 3 \
|
|
--inject-secret 736869e5-84f0-4973-92ec-06879ce3da0b:passwd.txt \
|
|
--secret-header secret-header.b64 \
|
|
--secret-payload secret-payload.b64
|
|
|
|
The ``secret-header.b64`` and ``secret-payload.b64`` files can now be sent to
|
|
the virtualization host for injection.
|
|
|
|
Fetch from remote libvirt
|
|
-------------------------
|
|
|
|
This scenario allows fetching certain data from a remote hypervisor via a
|
|
connection to libvirt. It will aid in debugging by analysing the guest
|
|
configuration and reporting anything that could invalidate the measurement
|
|
of the guest. This usage model is considered secure, because the limited
|
|
information obtained from the untrusted hypervisor cannot be used to change
|
|
the result.
|
|
|
|
Validate the measurement of a SEV guest booting from disk:
|
|
|
|
::
|
|
|
|
# virt-qemu-sev-validate \
|
|
--connect qemu+ssh://root@some.remote.host/system \
|
|
--firmware OVMF.sev.fd \
|
|
--tk this-guest-tk.bin \
|
|
--domain fedora34x86_64
|
|
|
|
Validate the measurement of a SEV guest with direct kernel boot:
|
|
|
|
::
|
|
|
|
# virt-qemu-sev-validate \
|
|
--connect qemu+ssh://root@some.remote.host/system \
|
|
--firmware OVMF.sev.fd \
|
|
--kernel vmlinuz-5.11.12 \
|
|
--initrd initramfs-5.11.12 \
|
|
--cmdline "root=/dev/vda1" \
|
|
--tk this-guest-tk.bin \
|
|
--domain fedora34x86_64
|
|
|
|
Validate the measurement of a SEV-ES SMP guest booting from disk:
|
|
|
|
::
|
|
|
|
# virt-qemu-sev-validate \
|
|
--connect qemu+ssh://root@some.remote.host/system \
|
|
--firmware OVMF.sev.fd \
|
|
--num-cpus 2 \
|
|
--vmsa-cpu0 vmsa0.bin \
|
|
--vmsa-cpu1 vmsa1.bin \
|
|
--tk this-guest-tk.bin \
|
|
--domain fedora34x86_64
|
|
|
|
Validate the measurement of a SEV-ES SMP guest booting from disk, with
|
|
automatically constructed VMSA:
|
|
|
|
::
|
|
|
|
# virt-qemu-sev-validate \
|
|
--connect qemu+ssh://root@some.remote.host/system \
|
|
--firmware OVMF.sev.fd \
|
|
--cpu-family 23 \
|
|
--cpu-model 49 \
|
|
--cpu-stepping 0 \
|
|
--tk this-guest-tk.bin \
|
|
--domain fedora34x86_64
|
|
|
|
Validate the measurement of a SEV guest booting from disk and
|
|
inject a disk password on success:
|
|
|
|
::
|
|
|
|
# virt-qemu-sev-validate \
|
|
--connect qemu+ssh://root@some.remote.host/system \
|
|
--firmware OVMF.sev.fd \
|
|
--tk this-guest-tk.bin \
|
|
--domain fedora34x86_64 \
|
|
--inject-secret 736869e5-84f0-4973-92ec-06879ce3da0b:passwd.txt
|
|
|
|
Fetch from local libvirt
|
|
------------------------
|
|
|
|
This scenario allows fetching all data from the local hypervisor via a
|
|
connection to libvirt. It is only to be used for the purpose of testing,
|
|
debugging, or demonstrations, because running on the local hypervisor is not
|
|
a secure scenario. To enable this usage, the ``--insecure`` flag must be
|
|
specified. Given a pointer to the libvirt guest to validate, all information
|
|
needed to perform a validation, except the TIK/TEK pair can be acquired
|
|
automatically.
|
|
|
|
Validate the measurement of a SEV guest booting from disk:
|
|
|
|
::
|
|
|
|
# virt-qemu-sev-validate \
|
|
--insecure \
|
|
--tk this-guest-tk.bin \
|
|
--domain fedora34x86_64
|
|
|
|
Validate the measurement of a SEV guest with direct kernel boot:
|
|
|
|
::
|
|
|
|
# virt-qemu-sev-validate \
|
|
--insecure \
|
|
--tk this-guest-tk.bin \
|
|
--domain fedora34x86_64
|
|
|
|
Validate the measurement of a SEV-ES SMP guest booting from disk:
|
|
|
|
::
|
|
|
|
# virt-qemu-sev-validate \
|
|
--insecure \
|
|
--vmsa-cpu0 vmsa0.bin \
|
|
--vmsa-cpu1 vmsa1.bin \
|
|
--tk this-guest-tk.bin \
|
|
--domain fedora34x86_64
|
|
|
|
Validate the measurement of a SEV-ES SMP guest booting from disk, with
|
|
automatically constructed VMSA:
|
|
|
|
::
|
|
|
|
# virt-qemu-sev-validate \
|
|
--insecure \
|
|
--tk this-guest-tk.bin \
|
|
--domain fedora34x86_64
|
|
|
|
Validate the measurement of a SEV guest booting from disk and
|
|
inject a disk password on success:
|
|
|
|
::
|
|
|
|
# virt-qemu-sev-validate \
|
|
--insecure \
|
|
--tk this-guest-tk.bin \
|
|
--domain fedora34x86_64 \
|
|
--inject-secret 736869e5-84f0-4973-92ec-06879ce3da0b:passwd.txt
|
|
|
|
COMMON MISTAKES CHECKLIST
|
|
=========================
|
|
|
|
The complexity of configuring a guest and validating its boot measurement
|
|
means it is very likely to see the failure::
|
|
|
|
ERROR: Measurement does not match, VM is not trustworthy
|
|
|
|
This error message assumes the worst, but in most cases will failure will be
|
|
a result of either mis-configuring the guest, or passing the wrong information
|
|
when trying to validate it. The following information is a guide for what
|
|
items to check in order to stand the best chance of diagnosing the problem
|
|
|
|
* Check the VM configuration for the DH certificate and session
|
|
blob in the libvirt guest XML.
|
|
|
|
The content for these fields should be in base64 format, which is
|
|
what ``sevctl session`` generates. Other tools may generate the files
|
|
in binary format, so ensure it has been correctly converted to base64.
|
|
|
|
* Check the VM configuration policy value matches the session blob
|
|
|
|
The ``<policy>`` value in libvirt guest XML has to match the value
|
|
passed to the ``sevctl session`` command. If this is mismatched
|
|
then the guest will not even start, and QEMU will show an error
|
|
such as::
|
|
|
|
sev_launch_start: LAUNCH_START ret=1 fw_error=11 'Bad measurement'
|
|
|
|
* Check the correct TIK/TEK keypair are passed
|
|
|
|
The TIK/TEK keypair are uniquely tied to each DH cert and session
|
|
blob. Make sure that the TIK/TEK keypair passed to this program
|
|
the ones matched to the DH cert and session blob configured for
|
|
the libvirt guest XML. This is one of the most common mistakes.
|
|
Further ensure that the TIK and TEK files are not swapped.
|
|
|
|
* Check the firmware binary matches the one used to boot
|
|
|
|
The firmware binary content is part of the data covered by the
|
|
launch measurement. Ensure that the firmware binary passed to
|
|
this program matches the one used to launch the guest. The
|
|
hypervisor host will periodically get software updates which
|
|
introduce a new firmware binary version.
|
|
|
|
* Check the kernel, initrd and cmdline match the one used to boot
|
|
|
|
If the guest is configured to use direct kernel boot, check that
|
|
the kernel, initrd and cmdline passed to this program match the
|
|
ones used to boot the guest. In the kernel cmdline whitespace
|
|
must be preserved exactly, including any leading or trailing
|
|
spaces.
|
|
|
|
* Check whether the kernel hash measurement is enabled
|
|
|
|
The ``kernelHashes`` property in the libvirt guest XML controls
|
|
whether hashes of the kernel, initrd and cmdline content are
|
|
covered by the boot measurement. If enabled, then the matching
|
|
content must be passed to this program. UIf disabled, then
|
|
the content must **NOT** be passed.
|
|
|
|
* Check that the correct measurement hash is passed
|
|
|
|
The measurement hash includes a nonce, so it will be different
|
|
on every boot attempt. Thus when validating the measuremnt it
|
|
is important ensure the most recent measurement is used.
|
|
|
|
* Check the correct VMSA blobs / CPU SKU values for the host are used
|
|
|
|
The VMSA blobs provide the initial register state for the
|
|
boot CPU and any additional CPUs. One of the registers
|
|
encodes the CPU SKU (family, model, stepping) of the physical
|
|
host CPU. Make sure that the VMSA blob used for validation
|
|
is one that matches the SKU of the host the guest is booted
|
|
on. Passing the CPU SKU values directly to the tool can
|
|
reduce the likelihood of using the wrong ones.
|
|
|
|
* Check the CPU count is correct
|
|
|
|
When passing VMSA blobs for SEV-ES guests, the number of CPUs
|
|
present will influence the measurement result. Ensure that the
|
|
correct vCPU count is used corresponding to the guest boot
|
|
attempt.
|
|
|
|
|
|
Best practice is to run this tool in completely offline mode and pass
|
|
all information as explicit command line parameters. When debugging
|
|
failures, however, it can be useful to tell it to connect to libvirt
|
|
and fetch information. If connecting to a remote libvirt instance,
|
|
it will fetch any information that can be trusted, which is the basic
|
|
VM launch state data. It will also sanity check the XML configuration
|
|
to identify some common mistakes. If the ``--insecure`` flag is passed
|
|
it can extract some configuration information and use that for the
|
|
attestation process.
|
|
|
|
If the mistake still can't be identified, then this tool can be run
|
|
on the virtualization host. In that scenario the only three command
|
|
line parameters required are for the TIK, TEK and libvirt domain
|
|
name. It should be able to automatically determine all the other
|
|
information required. If it still reports a failure, this points
|
|
very strongly to the TIK/TEK pair not matching the configured
|
|
DH certificate and session blob.
|
|
|
|
The ``--debug`` flag will display hashes and/or hex dumps for various
|
|
pieces of information used in the attestation process. Comparing the
|
|
``--debug`` output from running on the hypervisor host, against that
|
|
obtained when running in offline mode can give further guidance to
|
|
which parameter is inconsistent.
|
|
|
|
As mentioned earlier in this document, bear in mind that in general
|
|
any attestation answers obtained from running on the hypervisor host
|
|
should not be trusted. So if a configuration mistake is identified
|
|
it is strongly recommended to re-run the attestation in offline mode
|
|
on a trusted machine.
|
|
|
|
|
|
EXIT STATUS
|
|
===========
|
|
|
|
Upon successful attestation of the launch measurement, an exit status of 0 will
|
|
be set.
|
|
|
|
Upon failure to attest the launch measurement one of the following codes will
|
|
be set:
|
|
|
|
* **1** - *Guest measurement did not validate*
|
|
|
|
Assuming the inputs to this program are correct, the virtual machine launch
|
|
has been compromised and it should not be trusted henceforth.
|
|
|
|
* **2** - *Usage scenario cannot be supported*
|
|
|
|
The way in which this program has been invoked prevent it from being able to
|
|
validate the launch measurement.
|
|
|
|
* **3** - *Usage scenario is not secure*
|
|
|
|
The way in which this program has been invoked means that the result of any
|
|
launch measurement validation will not be secure.
|
|
|
|
The program can be reinvoked with ``--insecure`` argument to force a
|
|
validation, however, the results of this should not be trusted. This should
|
|
only be used for testing, debugging or demonstration purposes, never in a
|
|
production deployment.
|
|
|
|
* **4** - *Domain has incorrect configuration to be measured*
|
|
|
|
The way in which the guest has been configured prevent this program from being
|
|
able to validate the launch measurement. Note that in general the guest
|
|
configuration reported by the hypervisor is not trustworthy, so it is
|
|
possible this error could be a false positive designed to cause a denial of
|
|
service.
|
|
|
|
This program can be reinvoked with the ``--ignore-config`` argument to skip
|
|
the sanity checks on the domain XML. This will likely result in it failing
|
|
with an exit code of **1** indicating the measurement is invalid
|
|
|
|
* **5** - *Domain is in incorrect state to be measured*
|
|
|
|
The domain has to be running in order to validate a launch measurement.
|
|
|
|
* **6** - *unexpected error occurred in the code*
|
|
|
|
A logic flaw in this program means it is unable to complete the validation of
|
|
the measurement. This is a bug which should be reported to the maintainers.
|
|
|
|
AUTHOR
|
|
======
|
|
|
|
Daniel P. Berrangé
|
|
|
|
|
|
BUGS
|
|
====
|
|
|
|
Please report all bugs you discover. This should be done via either:
|
|
|
|
#. the mailing list
|
|
|
|
`https://libvirt.org/contact.html <https://libvirt.org/contact.html>`_
|
|
|
|
#. the bug tracker
|
|
|
|
`https://libvirt.org/bugs.html <https://libvirt.org/bugs.html>`_
|
|
|
|
Alternatively, you may report bugs to your software distributor / vendor.
|
|
|
|
|
|
COPYRIGHT
|
|
=========
|
|
|
|
Copyright (C) 2022 by Red Hat, Inc.
|
|
|
|
|
|
LICENSE
|
|
=======
|
|
|
|
``virt-qemu-sev-validate`` is distributed under the terms of the GNU LGPL v2.1+.
|
|
This is free software; see the source for copying conditions. There
|
|
is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
|
|
PURPOSE
|
|
|
|
|
|
SEE ALSO
|
|
========
|
|
|
|
virsh(1), `SEV launch security usage <https://libvirt.org/kbase/launch_security_sev.html>`_,
|
|
`https://libvirt.org/ <https://libvirt.org/>`_
|