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

[Christoffer Dall <christoffer.dall@xxxxxxxxxx>]

On Fri, Jan 27, 2017 at 05:44:15PM +0530, Bhupinder Thakur wrote:
> Hi,
> 
> I have done the changes for emulating pl011 in Xen. Currently, I have
> verified the emulation code by manually reading/writing data to
> /dev/ttyAMA0 which is the device file for pl011 device. The data is
> flowing fine between xenconsoled and the guest domain.
> 
> As a next step, I wanted to use /dev/ttyAMA0 as a console.
> 
> For that I tried adding console=ttyAMA0 instead of console=hvc0 in the
> "extra" directive in the domU configuration file. However, I do not
> see the output on the console once I attached the console using "xl
> console <domain_name>". I tried using "xl console -t serial
> <domain_name>" also but that shows the tty1 console and not the
> ttyAMA0 one.

I would try to verify that when Linux uses the pl011 as a console (as
opposed to just writing some characters into /dev/ttyAMA0), that it
doesn't error out somewhere.  So like Stefano suggests, make sure you
check the guest kernel log after boot (assuming you can SSH or something
into the box) and look at 'dmesg' to see if the pl011 driver failed.

You could also try adding some log info in you Xen pl011 emulation code
to see if the guest kernel driver prods the device in the sequence you
expect, based on looking at the linux driver for the pl011.

Thanks,
-Christoffer

> 
> 
> On 18 January 2017 at 00:57, Stefano Stabellini <sstabellini@xxxxxxxxxx> 
> wrote:
> > On Tue, 17 Jan 2017, Julien Grall wrote:
> >> Hi,
> >>
> >> Sorry for the late answer, I am just back from holidays and still 
> >> catching-up
> >> with my e-mails.
> >>
> >> On 03/01/17 20:08, Stefano Stabellini wrote:
> >> > On Thu, 29 Dec 2016, Bhupinder Thakur wrote:
> >> > > On 28 December 2016 at 23:19, Julien Grall <julien.grall@xxxxxxx> 
> >> > > 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.
> >> > >
> >> > > Please clarify what is meant by that no stage-2 mapping is required.
> >> > > Does it mean that no stage-2 mapping is required for the guest as it
> >> > > never needs to access this page?
> >> >
> >> > That's right.
> >> >
> >> >
> >> > > However, the Xen HYP will need the stage-2 mapping to find out the
> >> > > pl011 PFN --> physical MFN mapping so that it can map the page to its
> >> > > own address space. Currently, I am using prepare_ring_for_helper () to
> >> > > map the pl011 PFN (passed via hvm call) ---> phyiscal MFN ---> Xen HYP
> >> > > VA.
> >> >
> >> > I am not sure what Julien had in mind exactly. I like the idea of not
> >> > mapping the page at stage-2, but it is true that many interfaces expect
> >> > pfns. If Xen is the one to allocate the pl011 PV console page, then Xen
> >> > knows the mfn and could use it to map the page, instead of the pfn.
> >> > However, the PV console backend also needs to map the same page, and it
> >> > currently does that by calling xc_map_foreign_range, which I believe
> >> > also expect a pfn.
> >>
> >> Do you agree that page such as ioreq and the pl011 PV console are only used
> >> for communication between Xen and a backend?
> >
> > I agree
> >
> >
> >> We don't want the guest to access
> >> the content of the pages but still be able to map. I would guess that using
> >> the gfn was a convenience but has some security impact (see  guess using 
> >> the
> >> gfn is mostly for convenience but has some security impact today (see 
> >> XSA-197
> >> and XSA-199). AFAIU, we also want to account those pages to a domain.
> >
> > Right
> >
> >
> >> For the credit, this is a suggestion made by Andrew on IRC. If I remember
> >> correctly what he suggested, it would be to have an add-to-physmap version
> >> restricted for non-domU components (e.g backend, toolstack) which would 
> >> allow
> >> to map a given page (maybe via an index?).
> >>
> >> >
> >> > So maybe it is easier to use write-protection in stage-2 (as for ITS),
> >> > unless Julien has a better idea?
> >> >
> >>
> >> We need write-protection and also prevent the page to be removed.
> >>
> >> But to be fair, I would not bother to try to write-protect it for now if we
> >> are going towards keeping the pl011 console in the guest memory. I don't 
> >> think
> >> letting the guest writing in the console page is a big problem. The backend
> >> console should already be protected against malicious guest. If not, we are
> >> already in trouble as it part of the PV protocol :).
> >
> > True
> >
> >
> >> Regarding Xen, the console protocol is very easy and I think only bound
> >> checking is sufficient. So what a guest could do is hijacking its own 
> >> console.
> >> Any thoughts?
> >
> > I think you are correct, it is no different than providing a PV console
> > to a guest, which we already do.

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