Re: [Xen-devel] [RFC] WIP: optee: add OP-TEE mediator

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 4 Dec 2017, Volodymyr Babchuk wrote:
> Hi Julien,
> 
> 
> On Mon, Dec 04, 2017 at 04:27:14PM +0000, Julien Grall wrote:
> 
> [...]
> > >>= Error checking / DOS protection =
> > >>
> > >>We need powerful checks on arguments passed by the caller and evaluated
> > >>by the mediator.
> > >>
> > >>For example, we cannot expect the guest to actually pass arguments in
> > >>the format expected by translate_params. ctx->xen_arg could be
> > >>gibberish.
> > >Yes. The same arguments stands also for OP-TEE itself. OP-TEE checks
> > >validity of arguments and mediator should do the same. Actaully, I
> > >implemented this checks in mediator.
> > >
> > >> From the resource allocation point of view, it looks like every
> > >>handle_std_call allocates a new context; every copy_std_request
> > >>allocates a new Xen page. It would be easy to exhaust Xen resources.
> > >>Maybe we need a max concurrent request limit or max page allocation per
> > >>domain or something of the kind.
> > >This is a very good point. Thanks. Yes, it is currently missing.
> > >Is there any mechanism in XEN to provide quotas? I think, this mediator
> > >is not the single entity that allocates memory to handle guest calls?
> > 
> > Most of the time, the memory is either accounted to the guest or only a
> > small amount of memory is allocated for a known period of time (the time of
> > an hypercall for instance).
> Aha, so in my case, I will need to implement own quota mechanism.
> I think something like "max_pages", initialized with value from
> xenpolicy will be fine. What do you think?

Yes, that should work.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel