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

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi,

On 04/12/17 22:04, Stefano Stabellini wrote:
> 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.
I think "max_pages" will be difficult to size by a user. It would be 
better to think about another metrics  (e.g number of OP-TEE commands in 
//) and/or limit the use of xmalloc within the code.
Cheers,

--
Julien Grall

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