5:20 a.m.
On Tue, Aug 29, 2023 at 09:54:40AM +0200, Erik Skultety wrote:
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.
Even if the CPU had the "SEV-ES" feature, it doesn't mean you can use
it, because the firmware lets the hardware owner specify the split
between SEV & SEV-ES guests that are allowed on the machine. IOW even
if it supports SEV-ES, firmware could have been configured to have
zero SEV-ES guests.
For this reason, in the domain capabilities, the <sev supported='yes'>
element has child elements which give the info about the number of
configured guests of each type:
<sev supported='yes'>
...snip...
<maxGuests>10</maxGuests>
<maxESGuests>500</maxESGuests>
</sev>
Currently there is no SEV-SNP support merged in upstream Linux or
QEMU, and thus libvirt also does not support SEV-SNP. Once all the
pieces are merged in QEMU, we'll extend libvirt doman capabilities
to also reflect whether SEV-SNP is available.
NB, while SEV and SEV-ES can be thought of as just minor variations
of each other, I recommend that SEV-SNP be considered an entirely
separate confidential VM technology because architecturally SEV-SNP
is quite different from SEV/SEV-ES in the way that attestation is
driven from the guest, not the host. Long term I expect SEV/SEV-ES
to fade into irrelevance and SEV-SNP will be the only thing people
care about on AMD, because SNP is so much better.
> 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.
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 :|