qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] spapr: Add capability for Secure (PEF) VMs


From: David Gibson
Subject: Re: [PATCH] spapr: Add capability for Secure (PEF) VMs
Date: Thu, 7 May 2020 18:15:49 +1000

On Wed, May 06, 2020 at 09:12:51AM +0100, Dr. David Alan Gilbert wrote:
> * David Gibson (address@hidden) wrote:
> > On Tue, May 05, 2020 at 09:17:19AM +0100, Dr. David Alan Gilbert wrote:
> > > * David Gibson (address@hidden) wrote:
> > > > On Fri, May 01, 2020 at 04:02:49PM +1000, David Gibson wrote:
> > > > > Recent POWER9 machines have a system called PEF (Protected Execution
> > > > > Framework) which uses a small ultravisor to allow guests to run in a
> > > > > way that they can't be eavesdropped by the hypervisor.  The effect is
> > > > > roughly similar to AMD SEV, although the mechanisms are quite
> > > > > different.
> > > > > 
> > > > > Most of the work of this is done between the guest, KVM and the
> > > > > ultravisor, with little need for involvement by qemu.  However qemu
> > > > > does need to tell KVM to allow secure VMs.
> > > > > 
> > > > > Because the availability of secure mode is a guest visible difference
> > > > > which depends on havint the right hardware and firmware, we don't
> > > > > enable this by default.  In order to run a secure guest you need to
> > > > > set the new 'cap-allow-secure-guest' flag on.  Note that this just
> > > > > *allows* secure guests, the architecture of PEF is such that the guest
> > > > > still needs to talk to the ultravisor to enter secure mode, so we
> > > > > don't know if the guest actually is secure at machine creation time.
> > > > > 
> > > > > Signed-off-by: David Gibson <address@hidden>
> > > > 
> > > > Hm, so.  I'm reconsidering this.  I'm thinking I should probably try
> > > > to make this configuration more like what AMD SEV does, since this is
> > > > a very similar functionality.
> > > 
> > > Other than setting the 'we support PEF' flag, is there anything else
> > > you're going to have to do - for example with SEV there's stuff to pass
> > > a block of data and to do attestations and .... it's not just setting a
> > > flag; but my understanding of PEF it's more driven from the guest.
> > 
> > Yeah, with PEF there's not much.  Nonetheless I think I have a
> > reasonable way to partly unify the configuration, I hope to post some
> > patches shortly.
> > 
> > What we do want to do with PEF.. in fact, I suspect with all these
> > cases, is change some of the configuration defaults for virtio
> > (disable-legacy=on, iommu_platform=on), since with any guest whose
> > memory is protected from the hypervisor it will have to use normal DMA
> > channels rather than assuming it can access guest memory directly.
> 
> I think the same is true with SEV, but I don't think any of that is done
> automatically; we require users to set the correct flags to enable iommu
> on devices; doing it automatically feels like it makes sense.

Right.  I have some ideas on how to do this.  Again, patches soon, I
hope.

> Note also my 4ba59be1d6d8c that disables KSM for encrypted VMs; you
> probably want to do the same.

Yeah, I saw that.  In fact I think it's meaningless for power, because
the protection mechanism means that I don't think the host kernel can
even see the memory to attempt to KSM it.  But it makes ceonceptual
sense in any case, and making this more generic is something I expect
to have in this upcoming series.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]