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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 15 May 2017, George Dunlap wrote:
> [Reducing CC list now that we're off the topic of modules]
> 
> On Fri, May 12, 2017 at 8:04 PM, Volodymyr Babchuk
> <vlad.babchuk@xxxxxxxxx> wrote:
> > Stefano,
> >
> > On 12 May 2017 at 21:43, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
> >
> >> On the topic of the technical reasons for being out of the hypervisor
> >> (EL0 app or stubdom), I'll spend a couple of words on security.
> >>
> >> How large are these components? If they increase the hypervisor code
> >> size too much, it's best if they are run elsewhere.
> > I'm talking about OP-TEE now.
> > "Large" as "large code base"? I have shared my PoC driver. Here it is
> > [1]. My expectation: 1,000-2,000 lines of code for mediator + some
> > OP-TEE headers.
> >
> >> What is their guest-exposed attack surface? If it's large it's best to
> >> run them out of the hypervisor.
> > OP-TEE mediator will trap SMC calls and parse parameter buffers
> > according to OP-TEE ABI specification. ABI is very simple, so I can't
> > say that there will be attack surface.
> >
> >> My gut feeling is that both these points might be a problem.
> > The real problem, that is needs the same privileges, as hypervisor
> > itself. I wrote this in parallel thread:
> > it needs to pin guest pages (to ensure that page will be not
> > transferred to another domain, while OP-TEE uses it), it needs to map
> > guest page so it can do IPA->PA translation in a command buffer, it
> > needs to execute SMCs (but we can limit it there, thanks to SMCCC),
> > probably it will need to inject vIRQ to guest to wake it up.
> 
> Xen is different than Linux in that it attempts to take a "practical
> microkernel" approach.  "Microkernel" meaning that we prefer to do as
> much *outside* of the hypervisor as possible.  "Practical" meaning, if
> running it outside the hypervisor causes too much complexity or too
> much performance overhead, then we don't stand on ideology but allow
> things to run inside of Xen.
> 
> With the exception of SMCs (which I don't know anything about), device
> models (e.g., QEMU) already have  of this functionality on x86,
> running from dom0 or from a stubdomain.
> 
> Do OP-TEE mediators require a lot of performance?  I.e., do the
> operations happen very frequently and/or are they particularly
> latency-sensitive?  If not then it might be worth implementing it as a
> dom0 device model first, and then exploring higher-performing options
> if that turns out to be too slow.

The whole discussion started from the need for something that has lower
latency, and more importantly, more deterministic latency, than a dom0
device model.

Any use-cases with even the weakest of real-time requirements won't be
satisfied by a dom0 device model, where the max latency is basically
infinite.

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