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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 21 Dec 2016, Julien Grall wrote:
> Hi Stefano,
> 
> 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:
> > > > Finally, we cannot hijack one of the guest PV consoles, regardless of
> > > > whether it's the first console or one of the others, because the guest
> > > > can always try to use them at any time. We need a PV console reserved
> > > > for Xen-Dom0 communications on behalf of the guest. When a VM is created
> > > > with "pl011=y", the toolstack needs to allocate one more page and evtchn
> > > > for the exclusive hypervisor usage.  They are not going to be advertised
> > > > to the guest as PV consoles; otherwise, the guest could rightfully
> > > > access them.
> > > > 
> > > > Both Xen and the PV console backend need access to the two numbers (pfn
> > > > and evtchn) though. Xen doesn't do xenstore, so I suggest the toolstack
> > > > should use another way to tell pfn and evtchn to Xen, maybe hvm_params.
> > > 
> > > I think it will be the other way around. Xen will allocate the event
> > > channel
> > > and then report to the PV backends. Very similar to what it is done for
> > > ioreq
> > > server on x86 today.
> > 
> > It could work that way too. Even in the ioreq case though, the ioreq
> > parameters are still exposed via hvm_params (I am looking at
> > include/hw/xen/xen_common.h:xen_get_default_ioreq_server_info in QEMU).
> 
> I am fine with exposing the event channel via hvm_params. My previous mail was
> more related of who is allocating the event channel.
> 
> From my understanding, any event channel between Xen and a domain should
> currently be allocated by Xen via the function
> alloc_unbound_xen_event_channel.

OK
 
 
> > > > 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.


> [...]
> 
> > > IIRC, the UEFI firmware will use Xen console by default but I am not sure
> > > it
> > > will fallback to the PL011 if present. So we may require some change in
> > > the
> > > firmware to allow booting on different configuration (i.e PL011 guest or
> > > PV
> > > console guest).
> > 
> > Linux has checks to see if the pfn or evtchn are 0 and skips PV console
> > initialization in those cases. Tianocores probably has the same checks
> > (but I haven't read the code).
> 
> Probably, I am more concerned about Tianocore console not falling back on the
> PL011. The UEFI firmware is specifically built for Xen ARM guest, so I would
> be surprised to see a PL011 driver included.

Good point.

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