When SEV is enabled in domcapabilities does that just mean any of SEV, SEV-ES, SEV-SNP is possible on the hardware? 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? Sorry if these questions don't make sense or are ill-formed. Best, Derek
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
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 :|
participants (3)
-
Daniel P. Berrangé -
Derek Lee -
Erik Skultety