Re: SEV guest attestation

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Sergio Lopez (slp@redhat.com) wrote:
> On Thu, Nov 25, 2021 at 02:44:51PM +0200, Dov Murik wrote:
> > [+cc jejb, tobin, jim, hubertus]
> > 
> > 
> > On 25/11/2021 9:14, Sergio Lopez wrote:
> > > On Wed, Nov 24, 2021 at 06:29:07PM +0000, Dr. David Alan Gilbert wrote:
> > >> * Daniel P. Berrangé (berrange@redhat.com) wrote:
> > >>> 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.
> > >>
> > >> That's still not that clear; I know Alice and Sergio have some ideas
> > >> (cc'd).
> > >> There's also some standardisation efforts (e.g. https://www.potaroo.net/ietf/html/ids-wg-rats.html 
> > >> and https://www.ietf.org/archive/id/draft-ietf-rats-architecture-00.html
> > >> ) - that I can't claim to fully understand.
> > >> However, there are some themes that are emerging:
> > >>
> > >>   a) One use is to only allow a VM to access some private data once we
> > >> prove it's the VM we expect running in a secure/confidential system
> > >>   b) (a) normally involves requesting some proof from the VM and then
> > >> providing it some confidential data/a key if it's OK
> > >>   c) RATs splits the problem up:
> > >>     https://www.ietf.org/archive/id/draft-ietf-rats-architecture-00.html#name-architectural-overview
> > >>     I don't fully understand the split yet, but in principal there are
> > >> at least a few different things:
> > >>
> > >>   d) The comms layer
> > >>   e) Something that validates the attestation message (i.e. the
> > >> signatures are valid, the hashes all add up etc)
> > >>   f) Something that knows what hashes to expect (i.e. oh that's a RHEL
> > >> 8.4 kernel, or that's a valid kernel command line)
> > >>   g) Something that holds some secrets that can be handed out if e & f
> > >> are happy.
> > >>
> > >>   There have also been proposals (e.g. Intel HTTPA) for an attestable
> > >> connection after a VM is running; that's probably quite different from
> > >> (g) but still involves (e) & (f).
> > >>
> > >> In the simpler setups d,e,f,g probably live in one place; but it's not
> > >> clear where they live - for example one scenario says that your cloud
> > >> management layer holds some of them, another says you don't trust your
> > >> cloud management layer and you keep them separate.
> > >>
> > >> So I think all we're actually interested in at the moment, is (d) and
> > >> (e) and the way for (g) to get the secret back to the guest.
> > >>
> > >> Unfortunately the comms and the contents of them varies heavily with
> > >> technology; in some you're talking to the qemu/hypervisor (SEV/SEV-ES)
> > >> while in some you're talking to the guest after boot (SEV-SNP/TDX maybe
> > >> SEV-ES in some cases).
> > 
> > SEV-ES has pre-launch measurement and secret injection, just like SEV
> > (except that the measurement includes the initial states of all vcpus,
> > that is, their VMSAs.  BTW that means that in order to calculate the
> > measurement the Attestation Server must know exactly how many vcpus are
> > in the VM).
> 
> You need the number of vCPUs and an idea of what their initial state
> is going to be, to be able to reproduce the same VMSA struct in the
> Attestation Server.
> 
> This may tie the Attestation Server with a particular version of both
> QEMU and KVM. I haven't checked if configuration changes in QEMU may
> also have an impact on it.

That's all OK; I'm expecting the attestation server to be given a whole
pile of information about the apparent environment to check.

Dave

> Sergio.


-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK