On Mon, Aug 28, 2023 at 02:10:42PM -0700, Derek Lee
wrote:> When SEV is enabled in domcapabilities does that just mean any of SEV,
> SEV-ES, SEV-SNP is possible on the hardware?
No, <sev supported='yes'> only means that the CPU has
'sev' in the flags. On
its own it doesn't say anything about the ES/SNP features. It might be
possible
to extract information whether these have been enabled on the HW via BIOS (or
if they're enabled by default on new platforms) via the base64 encoded ID in
the <cpu0Id> XML subelement, but that's just my guess.
>
> Similarly, does enabling SEV as a launchSecurity option in a domainXML mean
> that whichever SEV is available will be enabled? And if the guest policy
> has the ES flag set, it will not be created unless ES is enabled?
Again, ES/SNP are just extra useful security features which sit on top of SEV
(i.e. there's no such thing as "whichever" SEV), both serving a
different
purpose and both supposed to be transparent to the user, IOW if they're
enabled
on the HW they'll be used.
Whether a VM is created if you explicitly request the ES flag via the guest
policy on a non-ES enabled SEV CPU is totally dependent on AMD's FW
behaviour
as libvirt only passes through the values. Based on the SEV API spec, if you
set ES in the guest policy SEV-ES must be enabled on the HW with no further
information provided, so my assumption is that the FW will refuse to comply
with such a request which in turn will result in QEMU returning a failure on
creating such a VM. Again, totally based on my assumption it would be a design
flaw of such a security feature if you requested the vCPU states to be included
in the measurement with the ES policy flag and the FW would silently ignore the
fact it's not enabled in HW and simply not include the data in the response.
Regards,
Erik