Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 5 May 2017, Andrii Anisov wrote:
> Hello Stefano,
> 
> On 24.04.17 21:08, Stefano Stabellini wrote:
> > Stubdomains (stubdoms in short) are small domains, each running a single
> > application. Typically they run unikernels rather than a full fledged
> > operating system. A classic example is QEMU stubdoms on x86: one QEMU
> > stubdoms is started for each regular guest domain. Each QEMU stubdom
> > instance provides emulation for one guest - it runs one instance of
> > QEMU.
> I'm wondering if there are any examples of practical usage of stub domains
> with ARM?

Good question. I don't think so: there have been practical examples of
unikernels running on Xen on ARM, but not stubdoms, because we haven't
needed to run large emulation pieces yet.


> >  From Xen point of view, they are regular domain, except that they are
> > privilege in regards to one particular guest only (they can map a page
> > of the guest they are servicing, but they cannot map any random page in
> > memory). If you do "xl list" you would see stubdoms in the output.
> So they are the regular XEN domains with sort of specific permissions.
> > The advantages of using stubdoms are:
> > - they already exist
> > - their security properties are well known
> Could you please point me to some up to date documentation about stubdoms and
> their security properties?

Stubdoms have been talked about in the Xen community for a very long
time:

https://hal.inria.fr/inria-00329969/PDF/final.pdf
http://www.cs.ubc.ca/~andy/papers/xoar-sosp-final.pdf
https://wiki.xen.org/wiki/Dom0_Disaggregation

Both OpenXT and Qubes OS use stubdoms.


> > In this thread, we are discussing whether it makes sense to introduce a
> > *new* model, one that has different properties, therefore different
> > advantages and disadvantages. Let's call it EL0 apps.
> > 
> > An EL0 app is an application that runs on top of the Xen hypervisor
> > directly in EL0 mode. It is not a domain, and it doesn't show up on "xl
> > list". It runs on the same timeslot of the guest vcpu it is servicing.
> > It is scheduled deterministically: right after a guest vcpu traps into
> > the hypervisor. The build is simple. Writing an EL0 app should be
> > (almost) as simple as writing a regular emulator for Xen. An EL0
> > app is not scheduled, but it could register a timer with Xen. The
> > interface between EL0 apps and Xen is small: the number of
> > functionalities exposed are very limited.
> Any reason to have an interface between XEN and EL0 app to be bound to an app
> functionality?
> Why not to introduce a generic (simplistic) interface and do not limit the
> functionality of the EL0 app?

Because if we did that there would be no security benefits in having EL0
apps: we might as well run the emulator in the hypervisor.


> > The advantages of using EL0 apps are:
> > - scheduled deterministically
> > - faster context switch
> > - lower and deterministic latency
> > - EL0 apps execution time is accounted appropriately to the guest that
> >    they are servicing
> Can't the EL0 app be servicing XEN itself?

Short answer: no.

Long answer follows. EL0 apps will run in a different context. It was
suggested to keep track of their state in the guest vcpu struct, which
looks like a good idea to me. If we did that, the only way to have an
EL0 app running without being bound to a specific guest, would be to run
it on the idle vcpu, which I think is a bad idea.

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