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

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 04/12/17 16:15, Volodymyr Babchuk wrote:
> Hi Stefano,
>
> On Fri, Dec 01, 2017 at 02:58:57PM -0800, Stefano Stabellini wrote:
> > On Mon, 27 Nov 2017, Volodymyr Babchuk wrote:
> > > This is follow-up to our conversation during community call.
> > > You asked me to send OP-TEE mediator as a patch, so we can
> > > discuss it in the mailing list. So, there it is. I squashed
> > > two patches into one and skipped patches that we already
> > > discussed.
> > >
> > > So, this is basically all what is needed to support OP-TEE in XEN.
> > > There are some TODOs left all over the code. But, I don't
> > > expect that TODOs implementation would significantly
> > > increase codebase. Currently mediator parses requests to perform
> > > addresses translation and that's all what is should be done
> > > to allow guests to work with OP-TEE.
> > >
> > > This become possible because I completely revisited virtualization
> > > support in OP-TEE. I have found way to enforce complete isolation
> > > between different guest states. This lifts many questions like usage
> > > quotas, RPC routing, sudden guest death, data isolation, etc.
> > >
> > > I'm aware that I didn't addressed all comments from previous
> > > discussion. Sorry for this. I'm currently busy with OP-TEE,
> > > and I think proper mediator implementation will be possible
> > > only after I'll stabilize OP-TEE part.
> > >
> > > So I don't ask anybody to do thorough review. I just want to
> > > share my status and discuss this code a whole.
> > Thank you for sharing! Actually, I think it is not too bad as a starting
> > point.
> >
> > I'll also try to summarize some key concept we have been discussing
> > about OP-TEE support in Xen.
> >
> >
> > = Xen cannot protect the system from a broken/insecure OP-TEE =
> >
> > OP-TEE runs at a higher privilege level than Xen, thus, we can't really
> > expect Xen to protect the system from a broken OP-TEE. Also, Xen cannot
> > really protect OP-TEE from a malicious caller.
> Yes, this is right.
>
> > What we can and should do is to protect Xen, the OP-TEE mediator in Xen
> > specifically, from malicious attackers.
> >
> > In other words, we are not responsible if a call, forwarded to OP-TEE by
> > Xen, ends up crashing OP-TEE, therefore taking down the system.
> >
> > However, we have to pay special care to avoid callers to crash or take
> > over the mediator in Xen. We also have to pay attention so that a caller
> > won't be able to exhaust Xen resources or DOS Xen (allocate too much
> > memory, infinite loops in Xen, etc). This brings me to the next topic.
> Yes, I see where are you going.
>
> > = 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).
> 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?
[..]

> > = 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.
Cheers,


--
Julien Grall

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