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

[Julien Grall <julien.grall@xxxxxxx>]

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.
Regards,

--
Julien Grall

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