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

Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest





On 28/12/16 17:49, Julien Grall wrote:
On 21/12/16 22:12, Stefano Stabellini wrote:
On Wed, 21 Dec 2016, Julien Grall wrote:
On 20/12/2016 20:53, Stefano Stabellini wrote:
On Tue, 20 Dec 2016, Julien Grall wrote:
On 19/12/2016 21:24, Stefano Stabellini wrote:
On Mon, 19 Dec 2016, Christoffer Dall wrote:
On Fri, Dec 16, 2016 at 05:03:13PM +0000, Julien Grall wrote:
If we use hvm_params for this, we need two new hvm_params and Xen
needs
to unmap the pfn from the guest immediately, because we don't want
the
guest to have access to it.

If you unmap the pfn, the PV backend will not be able to request
the page
because there will be no translation available.

So what you want to do is preventing the guest to at least write into
region
(not sure if it is worth to restrict read)

That's a good idea.


and unmap the page via the hypercall XENMEM_decrease_reservation.

That would be issued by the guest itself, right? To save address space?

Correct. The main use case today is ballooning, but guest could call
it on any
other RAM baked page.

I was thinking about more about the protection needed. Technically
the data in
the ring are not trusted. So if the guest is messing up with it, it
would not
be a big issue. Or did I miss anything here?

I understand that a guest would be smart to call
XENMEM_decrease_reservation on the PV console page for pl011, but it
cannot be a security measure, because, in fact, it needs to be called by
the guest.  Of course, a malicious guest can simply not call
XENMEM_decrease_reservation for it.

Sorry I was not clear. I was not suggested the guest to call
XENMEM_decrease_reservation on ring for security but a malicious guest
issuing the hypercall on the ring protected and replacing by another page.

This is the exact same problem as the one I mentioned on the ITS thread.
The page live in guest memory but contains data that will only be
touched by Xen.

If you remove those page from stage-2, the translation IPA -> MFN will
be lost unless you store somewhere else. You would have to do it
per-page as the buffer will use contiguous IPA but potentially
noncontiguous MFN.

In the case of ITS the memory is provisioned by the guest. So there are
not much to do there except adding protection in stage-2 such as write
protection and preventing the guest to unmap it. However for the pl011
ring, as Andrew pointed on IRC, what we need to do is accounting this
page to the domain memory. No mapping is necessary in stage-2.

I forgot to mention. The that backend of PV console is already considering the data in the ring untrusted. So I think in this case, protection is not strictly necessary. The worst thing that could happen is the guest is corrupting one of its console. Not really a big deal.

Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.