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

[Christoffer Dall <christoffer.dall@xxxxxxxxxx>]

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.

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.

-Christoffer

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