All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Sergio Lopez <slp@redhat.com>
Cc: afrosi@redhat.com, "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	qemu-devel@nongnu.org, dovmurik@linux.ibm.com,
	Tyler Fanelli <tfanelli@redhat.com>,
	dinechin@redhat.com, John Ferlan <jferlan@redhat.com>
Subject: Re: SEV guest attestation
Date: Thu, 25 Nov 2021 13:52:02 +0000	[thread overview]
Message-ID: <YZ+VAotzIOwUjMc8@redhat.com> (raw)
In-Reply-To: <20211125071428.dpnavgxd3w4bzktr@mhamilton>

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 :|



  parent reply	other threads:[~2021-11-25 13:54 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-24 16:34 SEV guest attestation Tyler Fanelli
2021-11-24 17:27 ` Tyler Fanelli
2021-11-24 17:49 ` Dr. David Alan Gilbert
2021-11-24 18:29   ` Tyler Fanelli
2021-11-24 17:57 ` Daniel P. Berrangé
2021-11-24 18:29   ` Dr. David Alan Gilbert
2021-11-25  7:14     ` Sergio Lopez
2021-11-25 12:44       ` Dov Murik
2021-11-25 13:42         ` Daniel P. Berrangé
2021-11-25 13:59           ` Dov Murik
2021-11-29 14:29             ` Brijesh Singh
2021-11-29 14:49               ` Brijesh Singh
2021-11-25 15:11         ` Sergio Lopez
2021-11-25 15:40           ` Dr. David Alan Gilbert
2021-11-25 15:56             ` Daniel P. Berrangé
2021-11-25 16:08               ` Dr. David Alan Gilbert
2021-11-29 13:33                 ` Dov Murik
2021-11-25 13:20       ` Dr. David Alan Gilbert
2021-11-25 13:36       ` Daniel P. Berrangé
2021-11-25 13:52       ` Daniel P. Berrangé [this message]
2021-11-25 13:55         ` Dov Murik
2021-11-25 15:00         ` Dr. David Alan Gilbert
2021-11-25 13:27     ` Daniel P. Berrangé
2021-11-25 13:50       ` Dov Murik
2021-11-25 13:56         ` Daniel P. Berrangé
2021-11-25 15:19       ` Dr. David Alan Gilbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YZ+VAotzIOwUjMc8@redhat.com \
    --to=berrange@redhat.com \
    --cc=afrosi@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=dinechin@redhat.com \
    --cc=dovmurik@linux.ibm.com \
    --cc=jferlan@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=slp@redhat.com \
    --cc=tfanelli@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.