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

[Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>]

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?

> >
> >Also, this problem is somewhat handled from OP-TEE site: it have limited
> >number of threads, so it can't handle many STD call simultaneously. But
> >I wouldn't rely on OP-TEE there, of course.
> 
> Does it mean OP-TEE will deny the call if it can't handle it? Or will it be
> put on hold?
OP-TEE will return OPTEE_SMC_RETURN_ETHREAD_LIMIT. Current behavior of
optee driver is to wait on a wait queue until another thread will
complete its call. So, from OP-TEE OS side - it is a call denial. But
from OP-TEE client point of view this is a hold, thanks to mentioned
behavior of driver.

> [..]
> 
> >>
> >>= Page pinning =
> >>
> >>Guest pages passed to OP-TEE need to be pinned (otherwise Xen doesn't
> >>guarantee they'll be available). I think the right function to call for
> >>that is get_page_from_gfn or get_page.
> >Yes, I need to pin pages. I have this in my TODO list. Question is how
> >to do this in a proper way. Julien has objections against get_page()
> >as I can see.
> 
> If you saw my objection about get_page(), you also saw my suggestions on how
> to do proper pinning in Xen.
Yes, I'm sorry, I missed second part of your email.


-- 
Volodymyr Babchuk

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