Re: Xen ARM - Exposing a PL011 to the guest

From: Stefano Stabellini <sstabellini@kernel.org>
To: Julien Grall <julien.grall@arm.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Steve Capper <Steve.Capper@arm.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Bhupinder Thakur <bhupinder.thakur@linaro.org>,
	Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: Xen ARM - Exposing a PL011 to the guest
Date: Tue, 3 Jan 2017 11:38:47 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.10.1701031138050.17742@sstabellini-ThinkPad-X260> (raw)
In-Reply-To: <b58fc8c9-fc04-389f-93de-f7105a437580@arm.com>

On Wed, 28 Dec 2016, Julien Grall wrote:
> Hi Stefano,
> 
> 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.

Thanks Julien for the explanation. I think you are right.

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