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

[George Dunlap <george.dunlap@citrix.com>]

On Fri, May 12, 2017 at 7:47 PM, Volodymyr Babchuk
<vlad.babchuk@gmail.com> wrote:
>> Regarding modules (#3): The problem that loadable modules were
>> primarily introduced to solve in Linux wasn't "How to deal with
>> proprietary drivers", or even "how to deal with out-of-tree drivers".
>> The problem was, "How to we allow software providers to 1) have a
>> single kernel binary, which 2) has drivers for all the different
>> systems on which it needs to run, but 3) not take a massive amount of
>> memory or space on systems, given that any given system will not need
>> the vast majority of drivers?"
>>
>> Suppose hypothetically that we decided that the mediators you describe
>> need to run in the hypervisor.  As long as Kconfig is sufficient for
>> people to enable or disable what they need to make a functional and
>> efficient system, then there's no need to introduce modules.  If we
>> reached a point where people wanted a single binary that could do
>> either or OP-TEE mediator or the Google mediator, or both, or neither,
>> but didn't to include all of them in the core binary (perhaps because
>> of memory constraints), then loadable modules would be a good solution
>> to consider.  But either way, if we decided they should run in the
>> hypervisor, then all things being equal it would still be better to
>> have both implementations in-tree.
>>
>> There are a couple of reasons for the push-back on loadable modules.
>> The first is the extra complication and infrastructure it adds.  But
>> the second is that people have a strong temptation to use them for
>> out-of-tree and proprietary code, both of which we'd like to avoid if
>> possible.  If there comes a point in time where loadable modules are
>> the only reasonable solution to the problem, I will support having
>> them; but until that time I will look for other solutions if I can.
>>
>> Does that make sense?
> Yes, thank you. Legal questions is not my best side. Looks like I was
> too quick, when proposed modules as a solution to our needs. Sorry, I
> had to investigate this topic further before talking about it.
>
> So, let's get back to native apps. We had internal discussion about
> possible use cases and want to share our conclusions.
>
> 1. Emulators. As Stefano pointed, this is ideal use case for small,
> fast native apps that are accounted in a calling vcpu time slice.
>
> 2. Virtual coprocessor backend/driver. The part that does actual job:
> makes coprocessor to save or restore context. It is also small,
> straightforward app, but it should have access to a real HW.
>
> 3. TEE mediators. They need so much privileges, so there actually are
> no sense in putting them into native apps. For example, to work
> properly OP-TEE mediator needs to: pin guest pages, map guest pages to
> perform IPA->MPA translation, send vIRQs to guests, issue real SMCs.

As I think I've said elsewhere, apart from "issue real SMCs", all of
that functionality is already available to device models running in
domain 0, in the sense that there are interfaces which cause Xen to
make those things happen: when the devicemodel maps a page, that
increases the refcount and effectively pins it; the devicemodel
accesses *all* guest pages in terms of guest memory addresses, but (I
believe) can ask Xen for a p->m translation of a particular page in
memory; and it can set vIRQs pending to the guest.  It seems likely
that a suitable hypervisor interface could be made to expose SMC
functionality to device models as well.

(Unless I've misunderstood something somewhere.)

Running it outside of dom0 could potentially be a security advantage
if you don't want to trust dom0 100%.

 -George

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