On Thu, Nov 25, 2021 at 08:14:28AM +0100, Sergio Lopez wrote: > For SEV-SNP, this is pretty much the end of the story, because the > attestation exchange is driven by an agent inside the guest. Well, > there's also the need to have in the VM a well-known vNIC bridged to a > network that's routed to the Attestation Server, that everyone seems > to consider a given, but to me, from a CSP perspective, looks like > quite a headache. In fact, I'd go as far as to suggest this > communication should happen through an alternative channel, such as > vsock, having a proxy on the Host, but I guess that depends on the CSP > infrastructure.
Allowing network connections from inside the VM, to any kind of host side mgmt LAN services is a big no for some cloud hosts. They usually desire for any guest network connectivity to be associated with a VLAN/network segment that is strictly isolated from any host mgmt LAN. OpenStack provides a virtual CCDROM for injecting cloud-init metadata as an alternative to the network based metadata REST service, since they latter often isn't deployed. Similarly for virtual filesystems, we've designed virtiofs, rather than relying on a 2nd NIC combined with NFS. We cannot assume availability of a real network device for the attestation. If one does exist fine, but there needs to be an alternative option that can be used. On a slightly different topic - if the attestation is driven from an agent inside the guest, this seems to imply we let the guest vCPUs start beforre attestation is done. Contrary to the SEV/SEV-ES where we seem to be wanting vCPUs to remain in the stopped state until attestation is complete & secrets provided. If the vCPUs are started, is there some mechanism to restrict what can be done before attestation is complete? 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 :|
