[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SEV guest attestation
From: |
Dr. David Alan Gilbert |
Subject: |
Re: SEV guest attestation |
Date: |
Thu, 25 Nov 2021 15:00:16 +0000 |
User-agent: |
Mutt/2.1.3 (2021-09-10) |
* Daniel P. Berrangé (berrange@redhat.com) wrote:
> 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.
That's right; SEV/SEV-ES is the odd case here.
> If the vCPUs are started, is there some mechanism
> to restrict what can be done before attestation is complete?
Just the fact you haven't provided it the keys to decrypt it's disk to
do anything interesting; there's the potential to add extra if you
wanted (e.g. 802.1X network auth).
Dave
>
> 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 :|
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
- Re: SEV guest attestation, (continued)
- Re: SEV guest attestation, Dr. David Alan Gilbert, 2021/11/24
- Re: SEV guest attestation, Sergio Lopez, 2021/11/25
- Re: SEV guest attestation, Dov Murik, 2021/11/25
- Re: SEV guest attestation, Daniel P . Berrangé, 2021/11/25
- Re: SEV guest attestation, Dov Murik, 2021/11/25
- Re: SEV guest attestation, Sergio Lopez, 2021/11/25
- Re: SEV guest attestation, Dr. David Alan Gilbert, 2021/11/25
- Re: SEV guest attestation, Daniel P . Berrangé, 2021/11/25
- Re: SEV guest attestation, Daniel P . Berrangé, 2021/11/25
- Re: SEV guest attestation, Dov Murik, 2021/11/25
- Re: SEV guest attestation,
Dr. David Alan Gilbert <=
- Re: SEV guest attestation, Daniel P . Berrangé, 2021/11/25
- Re: SEV guest attestation, Dov Murik, 2021/11/25
- Re: SEV guest attestation, Daniel P . Berrangé, 2021/11/25
- Re: SEV guest attestation, Dr. David Alan Gilbert, 2021/11/25