Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator

[Julien Grall <julien.grall@linaro.org>]

Hi Volodymyr,

On 24/10/17 20:02, Volodymyr Babchuk wrote:
>>>>>> If it is not safe, this means you have a whitelist solution and therefore
>>>>>> tie Xen to a specific OP-TEE version. So if you need to use a new function
>>>>>> you would need to upgrade Xen making the code of using new version
>>>>>> potentially high.
>>>>> Yes, any ABI change between OP-TEE and its clients will require mediator
>>>>> upgrade. Luckilly, OP-TEE maintains ABI backward-compatible, so if you'll
>>>>> install old XEN and new OP-TEE, OP-TEE will use only that subset of ABI,
>>>>> which is known to XEN.
>>>>>
>>>>>> Also, correct me if I am wrong, OP-TEE is a BSD 2-Clause. This means you
>>>>>> impose anyone wanted to modify OP-TEE for their own purpose can make a
>>>>>> closed version of the TEE. But if you need to introspect/whitelist call, you
>>>>>> impose the vendor to expose their API.
>>>>> Basically yes. Is this bad? OP-TEE driver in Linux is licensed under GPL v2.
>>>>> If vendor modifies interface between OP-TEE and Linux, they anyways obligued
>>>>> to expose API.
>>>>
>>>> Pardon me for potential stupid questions, my knowledge of OP-TEE is limited.
>>>>
>>>> My understanding is the OP-TEE will provide a generic way to access
>>>> different Trusted Application. While OP-TEE API may be generic, the TA API
>>>> is custom. AFAICT the latter is not part of Linux driver.
>>> Yes, you are perfectly right there.
>>>
>>>> So here my questions:
>>>> 	1) Are you planning allow all the guests to access every Trusted
>>>> Applications?
>>> This is a good question. There are two types of TAs supported in
>>> OP-TEE: real TAs (as they are described in GlobalPlatform specs) and
>>> PseudoTAs.  The latter ones are statically linked right into OP-TEE
>>> kernel and execute at S-EL1 level.
>>> Real TAs are provided by client. That means that NW userspace
>>> supplicant loads TA into OP-TEE. OP-TEE checks signature for the TA
>>> and then runs it in S-EL0.
>>> So, I'm planning to allow client to work with any real TA. I can't see
>>> real problem there.
>>
>> Are the real TAs going to be shared between guests? Or will each guest have
>> their own one?
> No, we don't plan this. At least at this momoent. Every guest will have
> own instance of TA.
> 
>> Will you allow every guests loading real TAs?
> Yes, if guest has access to TEE, it can load TA. Either there is no
> sense to use TEE. OP-TEE core itself does not provide useful services
> to clients.

In a previous e-mail you mentioned OP-TEE has limited memory. How will 
you ensure that guest A will not use all the memory of OP-TEE and 
prevent guest B to load TAs?

[...]

>> Not really, you could the domain could block when issuing an SMC until the
>> mediator is up and running.
> Do you mean, that if domain tries to execute SMC, and mediator is not
> ready, then hypervisor should pause all domain's vCPUs? That can be
> destructive for hw domain.

Xen is free to unschedule any vCPU at any time. So why would it be 
destructive?

[...]

>>>>>>> And yes, it seems obvious, but I want to say this explicitly: generic
>>>>>>> TEE mediator framework should and will use XSM to control which domain
>>>>>>> can work with TEE. So, if you don't trust your guest - don't let it
>>>>>>> to call TEE at all.
>>>>>>
>>>>>> Correct me if I am wrong. TEE could be used by Android guest which likely
>>>>>> run the user apps... right? So are you saying you fully trust that guest and
>>>>>> obviously the user installing rogue app?
>>>>> I don't think that app downloaded from Play Marget can access OP-TEE directly.
>>>>> OP-TEE can be used by Android itself as a key storage or to access to a SE,
>>>>> for example. But 3rd app that issues TEE calls... I don't think so.
>>>>
>>>> You didn't get my point here. That rogue app may be able to break into
>>>> kernel via an exploit or have enough privilege to break the guest. Who knows
>>>> what it will be able to do after...
>>> Only what hypervisor and TEE will allow it to do. Look, OP-TEE was not designed
>>> to rule the machine. There is ARM TF for that :) OP-TEE's task is to provide
>>> some safer environment for sensitive data and code. This environment has
>>> well-defined interfaces and is desgined to be as safe as possible.
>>>
>>> If rogue app breaks into kernel, then it can issue any SMC which it wants.
>>> But OP-TEE does not trust to NW. Hypervisor does not trust to guests.
>>> Mediator should be written in the same way.
>>>
>>> So, what can do rogue kernel? As I know - it can cause DoS in OP-TEE. This is
>>> known issue. If there is a security bug in OP-TEE, it probably can overcome
>>> whole system. But this is true for any system running OP-TEE.
>>
>> I agree that if you take over OP-TEE, you will take over any system. This is
>> not specific to hypervisor.
> Yes. But it just occured to me that mediator+OP-TEE *can* be more
> secure then just OP-TEE. You see, mediator should perform own security
> checks before forwarding call to OP-TEE. So if OP-TEE misses
> something, mediator can back it up. I wouldn't rely on this. It just
> interesting thought :-)
> 
>> Baremetal OS taking down the platform will only harm itself. A guest OS
>> could harm the whole platform.
> Can't argument with that. I think that this feature (shared TEE) is
> not suitable for, say, VPSes. But it can work just fine on smartphones
> or on another embedded devices, where vendor defines whole system.

I guess your use case is "vendor defines whole system". But I am 
struggling understand how this would more suitable there.

That guest OS may be "controlled" by the user. So how is that safer?

> 
>> What I am not sure yet, maybe because of my lack of knowledge around OP-TEE,
>> who is going to protect a TA to access all the NS memory?
> TAs is runing in S-EL0. It can't control MMU. Before every TA
> invocation, OP-TEE setups MMU in such way, so TA sees only shared
> memory arguments passed by client for this particular invocation.

Can you give a bit more details here? Particularly what is the life of 
that mapped region? Is it just for a command? If not, who is going to 
unmap it and when?

> 
>>>
>>> If there is a security flaw in mediator - it can compromise either hypervisor,
>>> or DomMediator and all TEE-capable guests. Yes, this is a risk.
>>>
>>>> The whole point of using an hypervisor is to isolate guest from each other.
>>>> So what is the isolation model with OP-TEE and the mediator?
>>> OP-TEE is written to isolate TAs, resources and clients from each other.
>>> Currently there are no plans for interaction between TAs from different VMs,
>>> no resource sharing, nothing like this.
>>> What do you mean under "isolation model"? Can you give some example?
>>
>> By that I meant, who is going to prevent guest A to access guest B data. I
>> think you partly answered to my question by the "OP-TEE is written to
>> isolate TAs". The access to NS memory question above will fill the rest I
>> think.
> Yes. Every TA is running in own context, and there are no trust even
> between TAs.

Glad to hear that.

[...]

>>>>>>>> To be clear, this series don't look controversial at least for OP-TEE. What
>>>>>>>> I am more concerned is about DomU supports.
>>>>>>> Your concern is that rogue DomU can compromise whole system, right?
>>>>>>
>>>>>> Yes. You seem to assume that DomU using TEE will always be trusted, I think
>>>>>> this is the wrong approach if the use is able to interact directly with
>>>>>> those guests. See above.
>>>>> No, I am not assuming that DomU that calls TEE should be trusted. Why do you
>>>>> think so? It should be able to use TEE services, but this does not mean that
>>>>> XEN should trust it.
>>>>
>>>> In a previous answer you said: "So, if you don't trust your guest - don't
>>>> let it". For me, this clearly means you consider that DomU using TEE are
>>>> trusted.
>>>>
>>>> So can you clarify by what you mean by trust then?
>>> Well... In real world "trust" isn't binary option. You don't want to
>>> allow all domains to access TEE. Breached TEE user domain doesn't
>>> automatically mean that your whole system is compromised. But this
>>> certainly increases attack surface. So it is safer to give TEE access
>>> only to those domains, which really require it. You can call them
>>> sligtly more trusted, then others.
>>
>> Do you have an example of guest you would slightly trust more?
> I have an example of guest I would trust less: if I'm running server,
> and I'm selling virtual machines on that server, I don't want to them
> to access TEE.

Make sense.

> 
> I will trust slightly more to my own guest.

I kind of agree if there are either no interaction with the user or the 
user is not able to gain privilege permissions.

> 
>>>
>>>>> Even now, XEN processes requests from DomUs without
>>>>> trusting them. Why do you think, that TEE mediator usage will differ?
>>>>
>>>> I guess you are comparing with vGIC and PL011? IHMO, the main difference is
>>>> Xen is taking care alone of the isolation between guest. Here in the TEE
>>>> case, you rely on a combination of both TEE and Xen to do the isolation.
>>> Yes. This is will be less secure, than TEE-only or hypervisor-only system.
>>
>> Can you expand here?
> If TEE has one security flaw and hypervisor has one security flaw,
> then you have two security flaws in your system. And any of them can
> compromise whole system.

Make sense.

>>>
>>>>>
>>>>> Look, I generally not against idea of TEE mediator in stubdoms. But this
>>>>> approach require many changes in existing XEN code:
>>>>>
>>>>> 1. Load domains before Dom0.
>>>>>
>>>>> 2. Add special API for mediator. Or alter existing ones. You can't use
>>>>>     existing APIs as it, because you need to enforce stricter XSM rules
>>>>>     on them.
>>>>
>>>> Mind giving more explanation....? Xen has a default policy for XSM and
>>>> indeed may not fit your use case. But you can write your own policy and load
>>>> it.
>>> Yes. You need policy "allow this stubdom to map memory only from TEE-enabled
>>> guests". AFAIK, this is not possible right now. But I can be wrong, I'm
>>> not very familiar with XSM.
>>
>> I believe XSM could do that. IIRC, you can "label" your domain and use that
>> to say "stubdom is allowed to access memory with domain using the given
>> label".
> Aha. This is good news. Thanks. Looks like I need to dig deeper into XSM...
> 
>>>
>>>>>
>>>>> 3. Changes in scheduling to allow TEE mediator use credits/slices of
>>>>>     calling guest.
>>>>>
>>>>> 4. Support boilerplate code in stubdom. You know, you can't simply
>>>>>     write mediator in stubdom. You need a kernel. You need to
>>>>>     maintain it.
>>>>
>>>> Well, in a way or another someone will have to maintain the mediator... The
>>>> kernel does not need to be specific to TEE, it could be a unikernel.
>>> Right. But for me XEN looks better maintained "kernel" :)
>>> IMHO, XEN is mature, there are less bugs (especially security ones)
>>> than in any other kernel.
>>>
>>>> And before you say again no-one in the community seem to be interested. I
>>>> should remind you that Arm is working on it (see development update).
>>> You are talking about that "unicore" project by NEC guys? Sorry,
>>> can't find mentioned development update. Looks like search on markmail
>>> is down (or I'm doing something terribly wrong).
>>
>> Sorry, I meant Mini-OS. I don't know any work on "unicore" for Arm64 for
>> now.
> Ah, good to hear. So there will be active maintainer for ARM64
> Mini-OS? Sorry, still can't find that "development update".

At the moment, the series is still in development. But yet the plan is 
to get Arm64 fully supported in Mini-OS.

> 
>>>
>>>>>
>>>>> This is a lot of a work. It requires changes in generic parts of XEN.
>>>>> I fear it will be very hard to upstream such changes, because no one
>>>>> sees an immediate value in them. How do you think, what are my chances
>>>>> to upstream this?
>>>>
>>>> It is fairly annoying to see you justifying back most of this thread with
>>>> "no one sees an immediate value in them".
>>>>
>>>> I am not the only maintainers in Xen, so effectively can't promise whether
>>>> it is going to be upstreamed. But I believe the community has been very
>>>> supportive so far, a lot of discussions happened (see [2]) because of the
>>>> OP-TEE support. So what more do you expect from us?
>>> I'm sorry, I didn't mean to offend you or someone else. You, guys, can
>>> be harsh sometimes, but I really appreciate help provided by the
>>> community. And I, certainly, don't ask you about any guarantees or
>>> something of that sort.
>>>
>>> I'm just bothered by amount of required work and by upstreaming
>>> process. But this is not a strong argument against mediators in
>>> stubdoms, I think :)
>>>
>>> Currently I'm developing virtualization support in OP-TEE, so in
>>> meantime we'll have much time to discuss mediators and stubdomain
>>> approach (if you have time). To test this feature in OP-TEE I'm
>>> extending this RFC, making optee.c to look like full-scale mediator.
>>> I need to do this anyways, to test OP-TEE. When I'll finish, I can
>>> show you how mediator can look like. Maybe this will persuade you to
>>> one or another approach.
>>
>> I think this would be useful. Can you also keep both Stefano (I assume he
>> wants too) and I  in the loop for the OP-TEE virtualization side?
> Okay. I'm planning to produce first RFC for OP-TEE folks in a few
> days. I'll subscribe you. In then meantime you can check out [2]

Thank you!

> [1] http://markmail.org/message/tdbg5mgxjvsoj2ph
> [2] https://github.com/OP-TEE/optee_os/issues/1890

Cheers,

-- 
Julien Grall

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