[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
signature.asc
Description: PGP signature
- RE: [PATCH] spapr: Add capability for Secure (PEF) VMs, (continued)