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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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