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, 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 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
element has child elements which give the info about the number of
configured guests of each type:
...snip...
10
500
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 :|
