[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |