Re: SEV guest attestation

[Daniel P . Berrangé]

On Wed, Nov 24, 2021 at 11:34:16AM -0500, Tyler Fanelli wrote:
> Hi,
> 
> We recently discussed a way for remote SEV guest attestation through QEMU.
> My initial approach was to get data needed for attestation through different
> QMP commands (all of which are already available, so no changes required
> there), deriving hashes and certificate data; and collecting all of this
> into a new QMP struct (SevLaunchStart, which would include the VM's policy,
> secret, and GPA) which would need to be upstreamed into QEMU. Once this is
> provided, QEMU would then need to have support for attestation before a VM
> is started. Upon speaking to Dave about this proposal, he mentioned that
> this may not be the best approach, as some situations would render the
> attestation unavailable, such as the instance where a VM is running in a
> cloud, and a guest owner would like to perform attestation via QMP (a likely
> scenario), yet a cloud provider cannot simply let anyone pass arbitrary QMP
> commands, as this could be an issue.

As a general point, QMP is a low level QEMU implementation detail,
which is generally expected to be consumed exclusively on the host
by a privileged mgmt layer, which will in turn expose its own higher
level APIs to users or other apps. I would not expect to see QMP
exposed to anything outside of the privileged host layer.

We also use the QAPI protocol for QEMU guest agent commmunication,
however, that is a distinct service from QMP on the host. It shares
most infra with QMP but has a completely diffent command set. On the
host it is not consumed inside QEMU, but instead consumed by a
mgmt app like libvirt. 

> So I ask, does anyone involved in QEMU's SEV implementation have any input
> on a quality way to perform guest attestation? If so, I'd be interested.

I think what's missing is some clearer illustrations of how this
feature is expected to be consumed in some real world application
and the use cases we're trying to solve.

I'd like to understand how it should fit in with common libvirt
applications across the different virtualization management
scenarios - eg virsh (command line),  virt-manger (local desktop
GUI), cockpit (single host web mgmt), OpenStack (cloud mgmt), etc.
And of course any non-traditional virt use cases that might be
relevant such as Kata.

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