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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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.

That said, PL011 is pretty small and the PL011 emulator needs to feed
data back to Dom0 for user interaction, so, if we need to, we could make
an exception for it and run it in userspace Dom0.

But do we really need to make an exception? I don't think so. The PL011
emulator could run in EL1 in Xen and connect to xenconsoled using the
regular PV console frontend/backend protocol, as you suggested. One
caveat: I would avoid introducing xenstore support in Xen, but
fortunately we don't need xenstore support for the first PV console
connection, so we should be OK. In any case if the xenconsole protocol
or xenconsoled are the problem, we could easily rewrite them or add
specific support for this new use case.

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