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

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



Hi,

The idea is for Xen to act as an intermediary as shown below:

               ring buffers
                           rx/tx fifo
dom0 <-------------------> Xen HYP (running pl011 emulation)
<-------------------> domU
                    event
                           interrupts

Xen will directly manage the in/out console ring buffers (allocated by
dom0 for dom0-domU console communication) for reading/writing console
data from/to dom0. On the other side, Xen HYP will emulate pl011 to
read/write data from/to domU and pass it on to/from dom0 over the
in/out console ring buffers. There should be no change in dom0 as it
will still use the same ring buffers. Similarly there should be no
change in domU which would be running a standard pll011 driver.

Currently, I am working on the interface between dom0 and Xen HYP. I
want to intercept the console events in Xen HYP which pass between
dom0 and domU. For now, I just want to capture console data coming
from dom0 at Xen HYP and loop it back to dom0, to confirm that this
interface is working.

Since each guest domain will have a unique event channel assigned for
console communication, Xen HYP can find out the event channel for a
given domU from the start_info page of that domU, which should have
been allocated by dom0. Whenever, an event is to be dispatched via
evtchn_send() API in Xen, it can check if the event channel is the
console event channel for a given domU. If yes and its source domain
is dom0 and destination domain is domU then it will write the data
back to the console out ring buffer of the domU and raise a console
event to dom0.

Once this interface is working, Xen HYP can check the source and
destination dom ids and decide which way the event came from and
accordingly process the console data. To allow a mix of PV console
guests and pl011 guests, Xen might have to maintain a flag per domain,
which tells whether Xen HYP should intercept and process the data (for
pl011 UART case) or let it go transparently (for PV conosle case).

Is this the correct way to find out the console event channel for a
given domU or there is some other way? I could not locate in the Xen
source code, where exactly the start_info page is created for a new
domain, which would contain the console event channel and and machine
page where the ring buffers are mapped.

Regards,
Bhupinder

On 2 December 2016 at 03:25, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
> On Thu, 1 Dec 2016, Christoffer Dall wrote:
>> On Wed, Nov 30, 2016 at 02:26:50PM -0800, Stefano Stabellini wrote:
>> > On Wed, 30 Nov 2016, Julien Grall wrote:
>> > > Hi all,
>> > >
>> > > Few months ago, Linaro has published the version 2 of the VM 
>> > > specification
>> > > [1].
>> > >
>> > > For those who don't know, the specification provides guidelines to 
>> > > guarantee a
>> > > compliant OS images could run on various hypervisor (e.g Xen, KVM).
>> > >
>> > > Looking at the specification, it will require Xen to expose new devices 
>> > > to the
>> > > guest: pl011, rtc, persistent flash (for UEFI variables).
>> > >
>> > > The RTC and persistent will only be used by the UEFI firwmare. The 
>> > > firwmare is
>> > > custom made for Xen guest and be loaded by the toolstack, so we could
>> > > theoretically provide PV drivers for those.
>> > >
>> > > This is not the case for the PL011. The guest will be shipped with a
>> > > PL011/SBSA UART driver,.This means it will expect to access it through 
>> > > MMIO.
>> > >
>> > > So we have to emulate a PL011. The question is where? Before suggesting 
>> > > some
>> > > ideas, the guest/user will expect to be able to interact with the console
>> > > through the UART. This means that the UART and xenconsoled needs to
>> > > communicate together.
>> > >
>> > > I think we can distinct two places where the PL011 could be emulated:
>> > > in the hypervisor, or outside the hypervisor.
>> > >
>> > > Emulating the UART in the hypervisor means that we take the risk to 
>> > > increase
>> > > to the attack surface of Xen if there is a bug in the emulation code. The
>> > > attack surface could be reduced by emulating the UART in another 
>> > > exception
>> > > level (e.g EL1, EL0) but still under the control of the hypervisor. 
>> > > Usually
>> > > the guest is communicating between with xenconsoled using a ring. For the
>> > > first console this could be discovered using hypercall HVMOP_get_param. 
>> > > For
>> > > the second and onwards, it described in xenstore. I would not worry too 
>> > > much
>> > > about emulating multiple PL011s, so we could implement the PV frontend 
>> > > in Xen.
>> > >
>> > > Emulating the UART outside the hypervisor (e.g in DOM0 or special domain)
>> > > would require to bring the concept of ioreq server on ARM. Which left the
>> > > question where do we emulate the PL011? The best place would be 
>> > > xenconsoled.
>> > > But I am not sure how would be the security impact here. Does all guest
>> > > consoles are emulated within the same daemon?
>> >
>> > One xenconsoled instance handles all PV console frontends. However QEMU,
>> > not xenconsoled, handles secondary PV consoles and emulated serials. One
>> > QEMU instance per VM. The PV console protocol is pretty trivial and not
>> > easy to exploit.
>> >
>> > Instead of emulating PL011 in xenconsoled we could do it in QEMU (or
>> > something like it). But I think we should do something else instead, see
>> > below.
>> >
>> >
>> > > I would lean towards the first solution if we implement all the security
>> > > safety I mentioned. Although, the second solution would be a good move 
>> > > if we
>> > > decide to implement more devices (e.g RTC, pflash) in the future.
>> > >
>> > > Do you have any opinions?
>> >
>> > As I have just written in this other email:
>> >
>> > http://marc.info/?l=xen-devel&m=148054285829397
>> >
>> > I don't think we should introduce userspace emulators in Dom0 on ARM.
>> > The reason is that they are bad both for security and performance. In
>> > general I think that the best solution is to introduce emulators in EL1
>> > in Xen.
>>
>> Slightly hijacking the discussion:
>>
>> Why would you run stuff in EL1 as opposed to EL0?
>>
>> My understanding of the HCR_EL2.TGE bit is exactly designed to run
>> bare-metal applications on top of a hypervisor running in EL2 and has
>> the added benefit that I think you can switch to your bare-metal
>> application without having to context-switch any EL1 tate, because TGE
>> just disabled the whole stage 1 MMU.  Obviously this doesn't give you
>> virtual memory, unless you map that using stage 2 tables, but that might
>> actually be preferred, and since the whole point is to separate your
>> non-privileged hypervisor applications from the hypervisor's memory
>> anyhow, it may be fine.
>>
>> I don't know enough about Xen's impementation to say whether this is
>> doable or not, but I think there are potential advantages in terms of
>> performance and using the architecture as designed.
>
> You might be right and it is definitely worth investigating.
>
>
>> Thinking about this, if you run something in EL1 on top of Xen without
>> setting the TGE bit, what happens if your application misbehaves, for
>> example causes a page fault?  That would be taken at EL1, right?  So
>> will you install an EL1 handler for exceptions that somehow forwards the
>> trap into EL2?  Sounds cleaner to me to catch anything weird the
>> application does to EL2.
>
> Yes, I think it would be better to handle that kind of faults at EL2.

_______________________________________________
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®.