[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20191108060548.GI5201@oc0525413822.ibm.com>
Date: Thu, 7 Nov 2019 22:05:48 -0800
From: Ram Pai <linuxram@...ibm.com>
To: Michael Ellerman <mpe@...erman.id.au>
Cc: linuxppc-dev@...ts.ozlabs.org, benh@...nel.crashing.org,
david@...son.dropbear.id.au, paulus@...abs.org,
mdroth@...ux.vnet.ibm.com, hch@....de, andmike@...ibm.com,
sukadev@...ux.vnet.ibm.com, mst@...hat.com, ram.n.pai@...il.com,
aik@...abs.ru, cai@....pw, tglx@...utronix.de,
bauerman@...ux.ibm.com, linux-kernel@...r.kernel.org
Subject: RE: [RFC v1 1/2] powerpc/pseries/iommu: Share the per-cpu TCE page with the
hypervisor.
On Thu, Nov 07, 2019 at 09:29:54PM +1100, Michael Ellerman wrote:
> Ram Pai <linuxram@...ibm.com> writes:
> > The hypervisor needs to access the contents of the page holding the TCE
> > entries while setting up the TCE entries in the IOMMU's TCE table. For
> > SecureVMs, since this page is encrypted, the hypervisor cannot access
> > valid entries. Share the page with the hypervisor. This ensures that the
> > hypervisor sees the valid entries.
>
> Can you please give people some explanation of why this is safe. After
> all the point of the Ultravisor is to protect the guest from a malicious
> hypervisor. Giving the hypervisor access to a page of TCEs sounds
> dangerous, so please explain why it's not.
Yes. will do, in my next version of the patch.
BTW: this page, which is shareed with the hypervisor contains nothing
but TCE entries. The hypervisor has a need to see those entries, so that it
can update the TCE table with correct entires.
Yes, a malicious hypervisor may try to update the TCE table with entries
that point to incorrect memory location. But doing so will not help the
hypervisor to steal any data from those memory location, because those
memory location; if accessed by the hypervisor, will only fetch
encrypted data.
At most it can lead to denial of service, but not stolen data.
RP
Powered by blists - more mailing lists