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

[Andrii Anisov <andrii_anisov@epam.com>]

Hello All,


On 10.05.17 12:56, George Dunlap wrote:
> But the context here is that Andrii asked something about whether this
> "EL0 App" functionality could be used to service Xen as well as a
> domain.  You said it didn't make sense, and Dario (as I understand it)
> was pointing out that we already did something similar with tasklets.
> If there was a need to be able to "upload" user-specified routines that
> would handle events generated by the hypervisor rather than events
> generated by a guest, that would indeed be a possibility.  It would
> essentially be the equivalent of a deprivileged, untrusted tasklet.
Actually that is what we are heavily interested in.
One more pro for a generic EL0 apps is that they could have different 
from XEN license. I.e. proprietary one.

> At the moment I can't foresee the need for such a mechanism, and I don't
> particularly think that we should keep that use case in mind when
> designing the "App" interface.  But it is an interesting idea to keep in
> our back pockets in case a use case comes up later.
I would provide few examples we have on the table:

  * fdtlib mentioned here [1] - just an example of a piece of some
    untrusted but virtually needed code.
  * a coprocessor platform support for SCF [2][3] - probably will be a
    piece of proprietary code, due to such IP specific functionalities
    like coprocessor task switching sequence and mmio access emulation.
  * some tee support code - support of trustee or mshield - proprietary one.

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2017-05/msg00381.html
[2] 
https://lists.xenproject.org/archives/html/xen-devel/2016-10/msg01966.html
[3] 
https://lists.xenproject.org/archives/html/xen-devel/2017-05/msg00348.html

-- 

*Andrii Anisov*



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