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

[Julien Grall]

Hi Volodymyr,

On 02/11/17 20:07, Volodymyr Babchuk wrote:

On Thu, Nov 02, 2017 at 05:49:12PM +, Julien Grall wrote:

On 02/11/17 16:53, Volodymyr Babchuk wrote:

On Thu, Nov 02, 2017 at 01:17:26PM +, Julien Grall wrote:

On 24/10/17 20:02, Volodymyr Babchuk wrote:

But parameters are mapped every call and only needed ones.
Example: I have shared buffers A, B, C, D.

1) I call OpenSession(TA_UUID, A, B).
TA sees only buffers A, B (okay, actually it sees whole page, because
buffer is mapped from userspace).

2) I call InvokeCommand(Session, CMD_ID, B, C).
TA sees only buffers B & C.

3) I call InvokeCommand(Session, CMD_ID, A, D).
TA sees only buffers A & D.

Note, that such buffers are not mapped at OP-TEE address space at all.
They will be mapped only to TA address space.


To confirm, what you are saying is as soon as any call is returned by TA,
the region will be unmapped from the TA address space?

Yes.
Also, just to clarify: TA executes only by request from client. It
can't have external events. So, TA address space is somewhat ephemeral
entity. It exists only during time between TA entry and TA exit. At
all other times, TA does have no address space, no thread context,
anything. Just code and data somewhere in memory.


That's quite a good news :). Thank you for the explanation.





[...]

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.

Okay, if user can execute arbitrary code at EL1... Even then nothing bad
will happen. They must be able to hack mediator/hypervisor/OP-TEE to realy
gain priviegs in system.


My worry here is you base the trust on OP-TEE and not only the hypervisor.
At the moment we had to trust the hardware to do the right thing and the
software is owned by Xen.

How about firmware? E.g. ARM TF?


My point here was anything involved in virtualization is at the moment 
the hardware and Xen. The ARM TF/firmware cannot be accessed 
directly/indirectly by any guest. So there are no concern to me.





Now you are telling me, we have this TEE running in EL3 and have to trust
him to do the isolation between guests. Until the last 2 e-mails, it was not
clear for me how OP-TEE could ensure this isolation.

Actually, OP-TEE is running at S-EL1 :-) Only ARM TF (or whatever
firmware is used) has ultimate control over the system. If we are
talking about modern ARMv8 platforms.


I would advise to explain a bit more in your cover letter of your next
version the design of OP-TEE. This would help people to see how this can
work with the hypervisor and also understanding the consequence...

I see. I'll do this, certainly. I just didn't expected that someone will
be interested in OP-TEE internals at such level.


I like to understand what I sign for :).



But, I think, cover leter for next OP-TEE will be done much later. Now,
I'm busy with OP-TEE part, then there will be changes to support
multi-domain boot and only then OP-TEE specific patches...

BTW, if anyone is interested in current state of OP-TEE mediator, you
can find it at [1]. I was able to pass OP-TEE tests from DomU in the
last version. I use it for OP-TEE development, so it is not
production-ready.

Julien, I want to ask about VM monitor feature in XEN. monitor_smc()
function and whole xen/arch/arm/monitor.c... Looks like it was
introduced for some sort of debugging. Do you know any users of this


It was originally introduced to allow an external application trapping 
SMC and executing an action. This is part of the VM introspection 
framework that could 

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

[Volodymyr Babchuk]

On Thu, Nov 02, 2017 at 05:49:12PM +, Julien Grall wrote:

Hi Julien,

> On 02/11/17 16:53, Volodymyr Babchuk wrote:
> >On Thu, Nov 02, 2017 at 01:17:26PM +, Julien Grall wrote:
> >>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?
> >There are no way to do this right now. Even on bare-metal system, one client
> >call load huge TA or eat up memory in another way to prevent other clients
> >to use OP-TEE. This is known limitation. It can be mitigated by enforcing
> >quotas.
> 
> Yes, but those clients only serve one OS. Here you would serve multiple
> OSes, clients from OS A could eat up the memory and prevent a client from OS
> B to run.
> 
> This could be a serious issue depending on how important the clients for OS
> are.
> 
> So likely enforcing quotas will be needed.
Yes. I agree there. I think, it is possible to implement them in mediator,
so we can use XSM to define quotas.

> >
> >>[...]
> >>
> 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?
> >Suppose that mediator domain needs 0.5s to boot up and be ready to
> >serve calls. For half of a second HW domain will be blocked. I don't
> >like the idea, that it will not be able to serve IRQs and other
> >requests. IMHO, it is okay for DomU, but not for Dom0.
> 
> 
> >
> >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 

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

[Julien Grall]

Hi Volodymyr,

On 02/11/17 16:53, Volodymyr Babchuk wrote:

On Thu, Nov 02, 2017 at 01:17:26PM +, Julien Grall wrote:

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?

There are no way to do this right now. Even on bare-metal system, one client
call load huge TA or eat up memory in another way to prevent other clients
to use OP-TEE. This is known limitation. It can be mitigated by enforcing
quotas.


Yes, but those clients only serve one OS. Here you would serve multiple 
OSes, clients from OS A could eat up the memory and prevent a client 
from OS B to run.


This could be a serious issue depending on how important the clients for 
OS are.


So likely enforcing quotas will be needed.




[...]


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?

Suppose that mediator domain needs 0.5s to boot up and be ready to
serve calls. For half of a second HW domain will be blocked. I don't
like the idea, that it will not be able to serve IRQs and other
requests. IMHO, it is okay for DomU, but not for Dom0.






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 

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

[Volodymyr Babchuk]

On Thu, Nov 02, 2017 at 01:17:26PM +, Julien Grall wrote:

Hi Julien,

> 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?
There are no way to do this right now. Even on bare-metal system, one client
call load huge TA or eat up memory in another way to prevent other clients
to use OP-TEE. This is known limitation. It can be mitigated by enforcing
quotas.

> [...]
> 
> >>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?
Suppose that mediator domain needs 0.5s to boot up and be ready to
serve calls. For half of a second HW domain will be blocked. I don't
like the idea, that it will not be able to serve IRQs and other
requests. IMHO, it is okay for DomU, but not for Dom0.

> >>>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.
> >>>
> 

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

[Julien Grall]

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 

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

[Julien Grall]

On 27 Oct 2017 20:59, "Stefano Stabellini"  wrote:

On Fri, 27 Oct 2017, Julien Grall wrote:
> Hi,
>
> Just answering to dom0 been 1:1 domain.
>
> On 24/10/17 22:33, Stefano Stabellini wrote:
> > On Tue, 24 Oct 2017, Volodymyr Babchuk wrote:
> > > > For this series, I think we need a way to specify which domains can
talk
> > > > to TEE, so that we can only allow it for a specific subset of
DomUs. I
> > > > would probably use XSM for that.
> > > I am afraid, this is not possible. As other domains aren't 1:1 mapped,
> > > I need to have special translation code in mediator. Actually, I'm
> > > writing it rigth now to test my changes in OP-TEE. But event this is
> > > not enought for decent OP-TEE support.
> > > What can be done right now: 100% Dom0-only support with vanilla
> > > OP-TEE (i.e. no virtualization support in OP-TEE is needed). This is
> > > even simplier task, so I can throw out some code from this patch
> > > series. On other hand, in the future this will lead to sutiation when
> > > two mediators for the same TEE shall be supported: one, simple, in
> > > XEN, another, fully-functional in stubdom.
> >
> > I think it is fine to support OP-TEE only in Dom0 to begin with.
> >
> > Ideally, it would be in Dom0 for convenience and speed and the OP-TEE
> > capability would be specified as an XSM label. Ideally, it would not be
> > only in Dom0 because it is tied to the 1:1 map, but I understand now
> > that it is a requirement. I still think that the XSM label would be good
> > to have even if today it cannot be changed as only Dom0 is 1:1.
>
> I thought a bit more about Dom0 been a 1:1 domain. It is only true for
Device
> Memory and the initial RAM allocated for Dom0.
>
> Dom0 may balloon out some pages because it has to map region belonging to
> other domain. Those regions will not be 1:1 mapped and translation will be
> needed if used.
>
> The problem is very similar to DMA in dom0. I can't see any reason to not
use
> those regions with OP-TEE. Am I wrong here?

I think you are right. For DMA, Dom0 is expected to use the swiotlb-xen
driver to solve the problem, because it is a genuine use case to have
foreign grants involved in a DMA operation.

For OP-TEE, I don't think we need to support this case? Xen could fail
the request if it involves a page that is not 1:1 mapped?


You would need to introspect the message in order to know that. So
supporting non 1:1 mapped page would not be more difficult.

This assuming that you know when you OP-TEE is done with the page.

Cheers,
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Stefano Stabellini]

On Fri, 27 Oct 2017, Julien Grall wrote:
> Hi,
> 
> Just answering to dom0 been 1:1 domain.
> 
> On 24/10/17 22:33, Stefano Stabellini wrote:
> > On Tue, 24 Oct 2017, Volodymyr Babchuk wrote:
> > > > For this series, I think we need a way to specify which domains can talk
> > > > to TEE, so that we can only allow it for a specific subset of DomUs. I
> > > > would probably use XSM for that.
> > > I am afraid, this is not possible. As other domains aren't 1:1 mapped,
> > > I need to have special translation code in mediator. Actually, I'm
> > > writing it rigth now to test my changes in OP-TEE. But event this is
> > > not enought for decent OP-TEE support.
> > > What can be done right now: 100% Dom0-only support with vanilla
> > > OP-TEE (i.e. no virtualization support in OP-TEE is needed). This is
> > > even simplier task, so I can throw out some code from this patch
> > > series. On other hand, in the future this will lead to sutiation when
> > > two mediators for the same TEE shall be supported: one, simple, in
> > > XEN, another, fully-functional in stubdom.
> > 
> > I think it is fine to support OP-TEE only in Dom0 to begin with.
> > 
> > Ideally, it would be in Dom0 for convenience and speed and the OP-TEE
> > capability would be specified as an XSM label. Ideally, it would not be
> > only in Dom0 because it is tied to the 1:1 map, but I understand now
> > that it is a requirement. I still think that the XSM label would be good
> > to have even if today it cannot be changed as only Dom0 is 1:1.
> 
> I thought a bit more about Dom0 been a 1:1 domain. It is only true for Device
> Memory and the initial RAM allocated for Dom0.
> 
> Dom0 may balloon out some pages because it has to map region belonging to
> other domain. Those regions will not be 1:1 mapped and translation will be
> needed if used.
> 
> The problem is very similar to DMA in dom0. I can't see any reason to not use
> those regions with OP-TEE. Am I wrong here?

I think you are right. For DMA, Dom0 is expected to use the swiotlb-xen
driver to solve the problem, because it is a genuine use case to have
foreign grants involved in a DMA operation.

For OP-TEE, I don't think we need to support this case? Xen could fail
the request if it involves a page that is not 1:1 mapped?

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

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

[Julien Grall]

Hi,

Just answering to dom0 been 1:1 domain.

On 24/10/17 22:33, Stefano Stabellini wrote:

On Tue, 24 Oct 2017, Volodymyr Babchuk wrote:

For this series, I think we need a way to specify which domains can talk
to TEE, so that we can only allow it for a specific subset of DomUs. I
would probably use XSM for that.

I am afraid, this is not possible. As other domains aren't 1:1 mapped,
I need to have special translation code in mediator. Actually, I'm
writing it rigth now to test my changes in OP-TEE. But event this is
not enought for decent OP-TEE support.
What can be done right now: 100% Dom0-only support with vanilla
OP-TEE (i.e. no virtualization support in OP-TEE is needed). This is
even simplier task, so I can throw out some code from this patch
series. On other hand, in the future this will lead to sutiation when
two mediators for the same TEE shall be supported: one, simple, in
XEN, another, fully-functional in stubdom.


I think it is fine to support OP-TEE only in Dom0 to begin with.

Ideally, it would be in Dom0 for convenience and speed and the OP-TEE
capability would be specified as an XSM label. Ideally, it would not be
only in Dom0 because it is tied to the 1:1 map, but I understand now
that it is a requirement. I still think that the XSM label would be good
to have even if today it cannot be changed as only Dom0 is 1:1.


I thought a bit more about Dom0 been a 1:1 domain. It is only true for 
Device Memory and the initial RAM allocated for Dom0.


Dom0 may balloon out some pages because it has to map region belonging 
to other domain. Those regions will not be 1:1 mapped and translation 
will be needed if used.


The problem is very similar to DMA in dom0. I can't see any reason to 
not use those regions with OP-TEE. Am I wrong here?


Cheers,

--
Julien Grall

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

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

[Stefano Stabellini]

On Tue, 24 Oct 2017, Volodymyr Babchuk wrote:
> > > > >Approach in this RFC is much simpler. Few hooks in arch code + 
> > > > >additional
> > > > >subsystem, which can be easily turned off.
> > > > 
> > > > Stefano do you have any opinion on this discussion?
> > 
> > We need to start somewhere, and I think this series could be a decent
> > starting point.
> >
> > I think it is OK to have a small SMC filter in Xen. What Volodymyr is
> > suggesting looks reasonable for now. As the code grows, we might found
> > ourselves in the situation where we'll have to introduce stubdoms for
> > TEE virtualization/emulation, and I think that's OK. Possibly, we'll
> > have a "fast path" in Xen, only for filtering and small manipulations,
> > and a "slow path" in the stubdom when more complex actions are
> > necessary.
> This sounds a bit tricky, actually. If I got you right, you are
> proposing to split mediator into two parts. Only benefit I can see
> there - fast calls to OP-TEE from Dom0. That probably can work, but I
> need to consider all consequences...

OK :-)


> > For this series, I think we need a way to specify which domains can talk
> > to TEE, so that we can only allow it for a specific subset of DomUs. I
> > would probably use XSM for that.
> I am afraid, this is not possible. As other domains aren't 1:1 mapped,
> I need to have special translation code in mediator. Actually, I'm
> writing it rigth now to test my changes in OP-TEE. But event this is
> not enought for decent OP-TEE support.
> What can be done right now: 100% Dom0-only support with vanilla
> OP-TEE (i.e. no virtualization support in OP-TEE is needed). This is
> even simplier task, so I can throw out some code from this patch
> series. On other hand, in the future this will lead to sutiation when
> two mediators for the same TEE shall be supported: one, simple, in
> XEN, another, fully-functional in stubdom.

I think it is fine to support OP-TEE only in Dom0 to begin with.

Ideally, it would be in Dom0 for convenience and speed and the OP-TEE
capability would be specified as an XSM label. Ideally, it would not be
only in Dom0 because it is tied to the 1:1 map, but I understand now
that it is a requirement. I still think that the XSM label would be good
to have even if today it cannot be changed as only Dom0 is 1:1.


> > For the long term, I think both Volodymyr and us as maintainers need to
> > be prepared to introduce stubdoms for TEE emulation. It will most
> > probably happen as the feature-set grows. However, this small TEE
> > framework in Xen could still be useful, and could be the basis for
> > forwarding TEE requests to a stubdom for evaluation: maybe not all calls
> > need to be forwarded to the stubdom, some of them could go directly to
> > the firmware and this is where this series comes in.
> > 
> > What do you think?
> Hmm... I can't imagine how this can work for OP-TEE. In OP-TEE
> protocol, there is a number of "fast" (in SMCCC terms) service calls,
> which called mostly during initialization (to probe UID and version,
> to get shared region location, to exchange caps and so on) and one
> "yielding" (again, SMCCC term) call for actuall TEE tasks. The later
> one passes arguments in command buffer (not in registers), it can
> cause so-called RPC returns (when OP-TEE asks Normal World to perform
> certain work). Most of the mediator code will be devoted to handle
> this one type of call. So, I don't see benefit in splitting mediator
> between XEN and stubdom. At least for OP-TEE. Maybe this is not true
> for other TEEs.
> Looks like Google Trusty employs another approach for NW<->SW
> communication, maybe it can work in theirs case...

It is possible to get a request from the command buffer in Xen, then
forward it to the stubdom over a separate ring. This is pretty much how
QEMU works on x86 to do emulation: IO accesses are trapped in Xen, then
Xen issues requests to QEMU over a special ring. Xen doesn't need to
forward to QEMU all requests: some of them could be handled directly in
Xen.

But maybe this model doesn't actually make sense for OP-TEE?

Would it make sense to extract a request from the ring in Xen then
evaluate whether it should be handled in Xen, forwarded to the firmware,
or forwarded to a stubdom?

For example, would it be possible to forward to firmware accesses to
certain TAs while forwarding to a stubdom accesses to other TAs?

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

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

[Volodymyr Babchuk]

Hi Julien, Jens,

I'm looped in Jens Wiklander. He is one of OP-TEE maintainers. He also
maintains TEE subsytem in Linux kernel. I CC'ed him in 4/4 patch,
because only it concerned OP-TEE. But looks like discussion in this
thread revolves primarily over OP-TEE, so I'm adding him there.

Jens, if you want to catch up, you can find whole thread at [1].

On Tue, Oct 24, 2017 at 06:33:20PM +0100, Julien Grall wrote:
> Hi,
> 
> On 23/10/17 21:11, Volodymyr Babchuk wrote:
> >On Mon, Oct 23, 2017 at 05:59:44PM +0100, Julien Grall wrote:
> >
> >>Hi Volodymyr,
> >Hi Julien,
> >
> >>Let me begin the e-mail with I am not totally adversed to putting the TEE
> >>mediator in Xen. At the moment, I am trying to understand the whole picture.
> >Thanks for clarification. This is really reassuring :)
> >In my turn, I'm not totally against TEE mediators in stubdoms. I'm only
> >concerned about required efforts.
> >
> >>On 20/10/17 18:37, Volodymyr Babchuk wrote:
> >>>On Fri, Oct 20, 2017 at 02:11:14PM +0100, Julien Grall wrote:
> On 17/10/17 16:59, Volodymyr Babchuk wrote:
> >On Mon, Oct 16, 2017 at 01:00:21PM +0100, Julien Grall wrote:
> >>On 11/10/17 20:01, Volodymyr Babchuk wrote:
> >>>I want to present TEE mediator, that was discussed earlier ([1]).
> >>>
> >>>I selected design with built-in mediators. This is easiest way,
> >>>it removes many questions, it is easy to implement and maintain
> >>>(at least I hope so).
> >>
> >>Well, it may close the technical questions but still leave the security
> >>impact unanswered. I would have appreciated a summary of each approach 
> >>and
> >>explain the pros/cons.
> >This is the most secure way also. In terms of trust between guests and
> >Xen at least. I'm worked with OP-TEE guys mostly, so when I hear about
> >"security", my first thoughts are "Can TEE OS trust to XEN as a
> >mediator? Can TEE client trust to XEN as a mediator?". And with
> >current approach answer is "yes, they can, especially if XEN is a part
> >of a chain of trust".
> >
> >But you probably wanted to ask "Can guest compromise whole system by
> >using TEE mediator or TEE OS?". This is an interesting question.
> >First let's discuss requirements for a TEE mediator. So, mediator
> >should be able to:
> >
> >  * Receive request to handle trapped SMC. This request should include
> >user registers + some information about guest (at least domain id).
> >  * Pin/unpin domain memory pages.
> >  * Map domain memory pages into own address space with RW access.
> >  * Issue real SMC to a TEE.
> >  * Receive information about guest creation and destruction.
> >  * (Probably) inject IRQs into a domain (this can be not a requester 
> > domain,
> >but some other domain, that also called to TEE).
> >
> >This is a minimal list of requirements. I think, this should be enough to
> >implement mediator for OP-TEE. But I can't say for sure for other TEEs.
> >
> >Let's consider possible approaches:
> >
> >1. Mediator right in XEN, works at EL2.
> >Pros:
> > * Mediator can use all XEN APIs
> > * As mediator resides in XEN, it can be checked together with XEN
> >   for a validity (trusted boot).
> > * Mediator is initialized before Dom0. Dom0 can work with a TEE.
> > * No extra context switches, no special ABI between XEN and 
> > mediator.
> >
> >Cons:
> > * Because it lives in EL2, it can compromise whole hypervisor,
> >   if there is a security bug in mediator code.
> > * No support for closed source TEEs.
> 
> Another cons is you assume TEE API is fully stable and will not change.
> Imagine a new function is added, or a vendor decided to hence with a new 
> set
> of API. How will you know Xen is safe to use it?
> >>>With whitelisting, as you correctly suggested below. XEN will process
> >>>only know requests. Anything that looks unfimiliar should be rejected.
> >>
> >>Let's imagine the guest is running on a platform with a newer version of
> >>TEE. This guest will probe the version of OP-TEE and knows the new function
> >>is present.
> >This request will be handled mediator. At this moment, OP-TEE client does
> >not use versions. Instead it uses capability flags. So, mediator should
> >filter all unknown caps. This will force guest to use only supported
> >subset of features.
> 
> One more question. Does it mean new functions will never be added in current
> capabilities?
AFAIK, now. That would break backward compatibility. 

> >If, in the future, client will relly on versions (i.e. due to dramatic
> >protocol change), mediator can either downgrade version or refuse to work
> >at all.
> 
> Makes sense.
> 
> >
> >>If as you said Xen is using a whitelist, this means the hypervisor will
> >>return unimplemented.
> >>How do you expect the guest to behave in 

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

[Julien Grall]

Hi,

On 23/10/17 21:11, Volodymyr Babchuk wrote:

On Mon, Oct 23, 2017 at 05:59:44PM +0100, Julien Grall wrote:


Hi Volodymyr,

Hi Julien,


Let me begin the e-mail with I am not totally adversed to putting the TEE
mediator in Xen. At the moment, I am trying to understand the whole picture.

Thanks for clarification. This is really reassuring :)
In my turn, I'm not totally against TEE mediators in stubdoms. I'm only
concerned about required efforts.


On 20/10/17 18:37, Volodymyr Babchuk wrote:

On Fri, Oct 20, 2017 at 02:11:14PM +0100, Julien Grall wrote:

On 17/10/17 16:59, Volodymyr Babchuk wrote:

On Mon, Oct 16, 2017 at 01:00:21PM +0100, Julien Grall wrote:

On 11/10/17 20:01, Volodymyr Babchuk wrote:

I want to present TEE mediator, that was discussed earlier ([1]).

I selected design with built-in mediators. This is easiest way,
it removes many questions, it is easy to implement and maintain
(at least I hope so).


Well, it may close the technical questions but still leave the security
impact unanswered. I would have appreciated a summary of each approach and
explain the pros/cons.

This is the most secure way also. In terms of trust between guests and
Xen at least. I'm worked with OP-TEE guys mostly, so when I hear about
"security", my first thoughts are "Can TEE OS trust to XEN as a
mediator? Can TEE client trust to XEN as a mediator?". And with
current approach answer is "yes, they can, especially if XEN is a part
of a chain of trust".

But you probably wanted to ask "Can guest compromise whole system by
using TEE mediator or TEE OS?". This is an interesting question.
First let's discuss requirements for a TEE mediator. So, mediator
should be able to:

  * Receive request to handle trapped SMC. This request should include
user registers + some information about guest (at least domain id).
  * Pin/unpin domain memory pages.
  * Map domain memory pages into own address space with RW access.
  * Issue real SMC to a TEE.
  * Receive information about guest creation and destruction.
  * (Probably) inject IRQs into a domain (this can be not a requester domain,
but some other domain, that also called to TEE).

This is a minimal list of requirements. I think, this should be enough to
implement mediator for OP-TEE. But I can't say for sure for other TEEs.

Let's consider possible approaches:

1. Mediator right in XEN, works at EL2.
Pros:
 * Mediator can use all XEN APIs
 * As mediator resides in XEN, it can be checked together with XEN
   for a validity (trusted boot).
 * Mediator is initialized before Dom0. Dom0 can work with a TEE.
 * No extra context switches, no special ABI between XEN and mediator.

Cons:
 * Because it lives in EL2, it can compromise whole hypervisor,
   if there is a security bug in mediator code.
 * No support for closed source TEEs.


Another cons is you assume TEE API is fully stable and will not change.
Imagine a new function is added, or a vendor decided to hence with a new set
of API. How will you know Xen is safe to use it?

With whitelisting, as you correctly suggested below. XEN will process
only know requests. Anything that looks unfimiliar should be rejected.


Let's imagine the guest is running on a platform with a newer version of
TEE. This guest will probe the version of OP-TEE and knows the new function
is present.

This request will be handled mediator. At this moment, OP-TEE client does
not use versions. Instead it uses capability flags. So, mediator should
filter all unknown caps. This will force guest to use only supported
subset of features.


One more question. Does it mean new functions will never be added in 
current capabilities?



If, in the future, client will relly on versions (i.e. due to dramatic
protocol change), mediator can either downgrade version or refuse to work
at all.


Makes sense.




If as you said Xen is using a whitelist, this means the hypervisor will
return unimplemented.
How do you expect the guest to behave in that case?

As I said above, guest should downgrade to supported features subset.


Note that I think a whitelist is a good idea, but I think we need to think a
bit more about the implication.

At least now OP-TEE is designed in a such way, that it is compatible in both
ways. I'm sure that future OP-TEE development will be done with virtualization
support in mind, so it will not break existing setups.


It would be good to have the two communities talking together. So we can 
make sure the virtualization support is not going in the wrong direction.


Similarly, it would be nice that someone from the OP-TEE maintainers 
give feedback on the approach suggested in Xen.







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

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

[Volodymyr Babchuk]

Hello Stefano

On Mon, Oct 23, 2017 at 02:26:56PM -0700, Stefano Stabellini wrote:

> > > >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.
> 
> Hi Volodymyr,
> 
> We really appreciate your work and we care about your use-case. We
> really want this feature to be successful for you (and everybody else).
> 
> Sorry if it doesn't always come out this way, but email conversations
> can sound "harsh" sometimes. However, keep in mind that both Julien and
> I are completely on your side on this work item. Please keep up with the
> good work :-)
Thanks :-)

> 
> > > >Approach in this RFC is much simpler. Few hooks in arch code + additional
> > > >subsystem, which can be easily turned off.
> > > 
> > > Stefano do you have any opinion on this discussion?
> 
> We need to start somewhere, and I think this series could be a decent
> starting point.
>
> I think it is OK to have a small SMC filter in Xen. What Volodymyr is
> suggesting looks reasonable for now. As the code grows, we might found
> ourselves in the situation where we'll have to introduce stubdoms for
> TEE virtualization/emulation, and I think that's OK. Possibly, we'll
> have a "fast path" in Xen, only for filtering and small manipulations,
> and a "slow path" in the stubdom when more complex actions are
> necessary.
This sounds a bit tricky, actually. If I got you right, you are
proposing to split mediator into two parts. Only benefit I can see
there - fast calls to OP-TEE from Dom0. That probably can work, but I
need to consider all consequences...

> For this series, I think we need a way to specify which domains can talk
> to TEE, so that we can only allow it for a specific subset of DomUs. I
> would probably use XSM for that.
I am afraid, this is not possible. As other domains aren't 1:1 mapped,
I need to have special translation code in mediator. Actually, I'm
writing it rigth now to test my changes in OP-TEE. But event this is
not enought for decent OP-TEE support.
What can be done right now: 100% Dom0-only support with vanilla
OP-TEE (i.e. no virtualization support in OP-TEE is needed). This is
even simplier task, so I can throw out some code from this patch
series. On other hand, in the future this will lead to sutiation when
two mediators for the same TEE shall be supported: one, simple, in
XEN, another, fully-functional in stubdom.

> For the long term, I think both Volodymyr and us as maintainers need to
> be prepared to introduce stubdoms for TEE emulation. It will most
> probably happen as the feature-set grows. However, this small TEE
> framework in Xen could still be useful, and could be the basis for
> forwarding TEE requests to a stubdom for evaluation: maybe not all calls
> need to be forwarded to the stubdom, some of them could go directly to
> the firmware and this is where this series comes in.
> 
> What do you think?
Hmm... I can't imagine how this can work for OP-TEE. In OP-TEE
protocol, there is a number of "fast" (in SMCCC terms) service calls,
which called mostly during initialization (to probe UID and version,
to get shared region location, to exchange caps and so on) and one
"yielding" (again, SMCCC term) call for actuall TEE tasks. The later
one passes arguments in command buffer (not in registers), it can
cause so-called RPC returns (when OP-TEE asks Normal World to perform
certain work). Most of the mediator code will be devoted to handle
this one type of call. So, I don't see benefit in splitting mediator
between XEN and stubdom. At least for 

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

[Stefano Stabellini]

On Mon, 23 Oct 2017, Volodymyr Babchuk wrote:
> > >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.

Hi Volodymyr,

We really appreciate your work and we care about your use-case. We
really want this feature to be successful for you (and everybody else).

Sorry if it doesn't always come out this way, but email conversations
can sound "harsh" sometimes. However, keep in mind that both Julien and
I are completely on your side on this work item. Please keep up with the
good work :-)


> > >Approach in this RFC is much simpler. Few hooks in arch code + additional
> > >subsystem, which can be easily turned off.
> > 
> > Stefano do you have any opinion on this discussion?

We need to start somewhere, and I think this series could be a decent
starting point.

I think it is OK to have a small SMC filter in Xen. What Volodymyr is
suggesting looks reasonable for now. As the code grows, we might found
ourselves in the situation where we'll have to introduce stubdoms for
TEE virtualization/emulation, and I think that's OK. Possibly, we'll
have a "fast path" in Xen, only for filtering and small manipulations,
and a "slow path" in the stubdom when more complex actions are
necessary.

For this series, I think we need a way to specify which domains can talk
to TEE, so that we can only allow it for a specific subset of DomUs. I
would probably use XSM for that.

For the long term, I think both Volodymyr and us as maintainers need to
be prepared to introduce stubdoms for TEE emulation. It will most
probably happen as the feature-set grows. However, this small TEE
framework in Xen could still be useful, and could be the basis for
forwarding TEE requests to a stubdom for evaluation: maybe not all calls
need to be forwarded to the stubdom, some of them could go directly to
the firmware and this is where this series comes in.

What do you think?

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

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

[Volodymyr Babchuk]

On Mon, Oct 23, 2017 at 05:59:44PM +0100, Julien Grall wrote:

> Hi Volodymyr,
Hi Julien,

> Let me begin the e-mail with I am not totally adversed to putting the TEE
> mediator in Xen. At the moment, I am trying to understand the whole picture.
Thanks for clarification. This is really reassuring :)
In my turn, I'm not totally against TEE mediators in stubdoms. I'm only
concerned about required efforts.

> On 20/10/17 18:37, Volodymyr Babchuk wrote:
> >On Fri, Oct 20, 2017 at 02:11:14PM +0100, Julien Grall wrote:
> >>On 17/10/17 16:59, Volodymyr Babchuk wrote:
> >>>On Mon, Oct 16, 2017 at 01:00:21PM +0100, Julien Grall wrote:
> On 11/10/17 20:01, Volodymyr Babchuk wrote:
> >I want to present TEE mediator, that was discussed earlier ([1]).
> >
> >I selected design with built-in mediators. This is easiest way,
> >it removes many questions, it is easy to implement and maintain
> >(at least I hope so).
> 
> Well, it may close the technical questions but still leave the security
> impact unanswered. I would have appreciated a summary of each approach and
> explain the pros/cons.
> >>>This is the most secure way also. In terms of trust between guests and
> >>>Xen at least. I'm worked with OP-TEE guys mostly, so when I hear about
> >>>"security", my first thoughts are "Can TEE OS trust to XEN as a
> >>>mediator? Can TEE client trust to XEN as a mediator?". And with
> >>>current approach answer is "yes, they can, especially if XEN is a part
> >>>of a chain of trust".
> >>>
> >>>But you probably wanted to ask "Can guest compromise whole system by
> >>>using TEE mediator or TEE OS?". This is an interesting question.
> >>>First let's discuss requirements for a TEE mediator. So, mediator
> >>>should be able to:
> >>>
> >>>  * Receive request to handle trapped SMC. This request should include
> >>>user registers + some information about guest (at least domain id).
> >>>  * Pin/unpin domain memory pages.
> >>>  * Map domain memory pages into own address space with RW access.
> >>>  * Issue real SMC to a TEE.
> >>>  * Receive information about guest creation and destruction.
> >>>  * (Probably) inject IRQs into a domain (this can be not a requester 
> >>> domain,
> >>>but some other domain, that also called to TEE).
> >>>
> >>>This is a minimal list of requirements. I think, this should be enough to
> >>>implement mediator for OP-TEE. But I can't say for sure for other TEEs.
> >>>
> >>>Let's consider possible approaches:
> >>>
> >>>1. Mediator right in XEN, works at EL2.
> >>>Pros:
> >>> * Mediator can use all XEN APIs
> >>> * As mediator resides in XEN, it can be checked together with XEN
> >>>   for a validity (trusted boot).
> >>> * Mediator is initialized before Dom0. Dom0 can work with a TEE.
> >>> * No extra context switches, no special ABI between XEN and mediator.
> >>>
> >>>Cons:
> >>> * Because it lives in EL2, it can compromise whole hypervisor,
> >>>   if there is a security bug in mediator code.
> >>> * No support for closed source TEEs.
> >>
> >>Another cons is you assume TEE API is fully stable and will not change.
> >>Imagine a new function is added, or a vendor decided to hence with a new set
> >>of API. How will you know Xen is safe to use it?
> >With whitelisting, as you correctly suggested below. XEN will process
> >only know requests. Anything that looks unfimiliar should be rejected.
> 
> Let's imagine the guest is running on a platform with a newer version of
> TEE. This guest will probe the version of OP-TEE and knows the new function
> is present.
This request will be handled mediator. At this moment, OP-TEE client does
not use versions. Instead it uses capability flags. So, mediator should
filter all unknown caps. This will force guest to use only supported
subset of features.
If, in the future, client will relly on versions (i.e. due to dramatic
protocol change), mediator can either downgrade version or refuse to work
at all.

> If as you said Xen is using a whitelist, this means the hypervisor will
> return unimplemented.
> How do you expect the guest to behave in that case?
As I said above, guest should downgrade to supported features subset.

> Note that I think a whitelist is a good idea, but I think we need to think a
> bit more about the implication.
At least now OP-TEE is designed in a such way, that it is compatible in both
ways. I'm sure that future OP-TEE development will be done with virtualization
support in mind, so it will not break existing setups.

> >
> >>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 

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

[Julien Grall]

Hi Volodymyr,

Let me begin the e-mail with I am not totally adversed to putting the 
TEE mediator in Xen. At the moment, I am trying to understand the whole 
picture.


On 20/10/17 18:37, Volodymyr Babchuk wrote:

On Fri, Oct 20, 2017 at 02:11:14PM +0100, Julien Grall wrote:

On 17/10/17 16:59, Volodymyr Babchuk wrote:

On Mon, Oct 16, 2017 at 01:00:21PM +0100, Julien Grall wrote:

On 11/10/17 20:01, Volodymyr Babchuk wrote:

I want to present TEE mediator, that was discussed earlier ([1]).

I selected design with built-in mediators. This is easiest way,
it removes many questions, it is easy to implement and maintain
(at least I hope so).


Well, it may close the technical questions but still leave the security
impact unanswered. I would have appreciated a summary of each approach and
explain the pros/cons.

This is the most secure way also. In terms of trust between guests and
Xen at least. I'm worked with OP-TEE guys mostly, so when I hear about
"security", my first thoughts are "Can TEE OS trust to XEN as a
mediator? Can TEE client trust to XEN as a mediator?". And with
current approach answer is "yes, they can, especially if XEN is a part
of a chain of trust".

But you probably wanted to ask "Can guest compromise whole system by
using TEE mediator or TEE OS?". This is an interesting question.
First let's discuss requirements for a TEE mediator. So, mediator
should be able to:

  * Receive request to handle trapped SMC. This request should include
user registers + some information about guest (at least domain id).
  * Pin/unpin domain memory pages.
  * Map domain memory pages into own address space with RW access.
  * Issue real SMC to a TEE.
  * Receive information about guest creation and destruction.
  * (Probably) inject IRQs into a domain (this can be not a requester domain,
but some other domain, that also called to TEE).

This is a minimal list of requirements. I think, this should be enough to
implement mediator for OP-TEE. But I can't say for sure for other TEEs.

Let's consider possible approaches:

1. Mediator right in XEN, works at EL2.
Pros:
 * Mediator can use all XEN APIs
 * As mediator resides in XEN, it can be checked together with XEN
   for a validity (trusted boot).
 * Mediator is initialized before Dom0. Dom0 can work with a TEE.
 * No extra context switches, no special ABI between XEN and mediator.

Cons:
 * Because it lives in EL2, it can compromise whole hypervisor,
   if there is a security bug in mediator code.
 * No support for closed source TEEs.


Another cons is you assume TEE API is fully stable and will not change.
Imagine a new function is added, or a vendor decided to hence with a new set
of API. How will you know Xen is safe to use it?

With whitelisting, as you correctly suggested below. XEN will process
only know requests. Anything that looks unfimiliar should be rejected.


Let's imagine the guest is running on a platform with a newer version of 
TEE. This guest will probe the version of OP-TEE and knows the new 
function is present.


If as you said Xen is using a whitelist, this means the hypervisor will 
return unimplemented.


How do you expect the guest to behave in that case?

Note that I think a whitelist is a good idea, but I think we need to 
think a bit more about the implication.





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.


So here my questions:
	1) Are you planning allow all the guests to access every Trusted 
Applications?

2) Will you ever need to introspect those messages?



2. Mediator in a stubdomain. Works at EL1.
Pros:
 * Mediator is isolated from hypervisor (but it still can do potentially
   dangerous things like mapping domain memory or pining pages).
 * One can legally create and use mediator for a closed-source TEE.


* Easier 

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

[Volodymyr Babchuk]

On 20.10.17 19:57, Tamas K Lengyel wrote:

Hello Tamas,


In previous discussion we considered only two variants: in XEN or outside
XEN. Stubdomain approach looks more secure, but I'm not sure that it is
true.
Such stubdomain will need access to all guests memory. If you managed to
gain control on mediator stubdomain, you can do anything you want with all
guests.



That's slightly untrue. The stubdomain will only be able to mess with
domains using TEE.


Would it be feasible to have multiple TEE stubdoms providing the
interface for select domUs (with XSM)? IMHO that would provide the
greatest disaggregation and thus the most security.
If we wanted to provide every DomU with own instance of virtual TEE - 
that would work. But we want to allow DomUs to work with real a TEE.
Thus we need TEE mediator, and mediator will need to have a shared 
state. So we can't split it among multiple stubdoms.



WBR Volodymyr Babchuk


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

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

[Volodymyr Babchuk]

On Fri, Oct 20, 2017 at 02:11:14PM +0100, Julien Grall wrote:
> Hi Volodymyr,
Hi Julien,

> On 17/10/17 16:59, Volodymyr Babchuk wrote:
> >On Mon, Oct 16, 2017 at 01:00:21PM +0100, Julien Grall wrote:
> >>
> >>
> >>On 11/10/17 20:01, Volodymyr Babchuk wrote:
> >>>Hello all,
> >>
> >>Hi Volodymyr,
> >Hi Julien
> >>
> >>>
> >>>I want to present TEE mediator, that was discussed earlier ([1]).
> >>>
> >>>I selected design with built-in mediators. This is easiest way,
> >>>it removes many questions, it is easy to implement and maintain
> >>>(at least I hope so).
> >>
> >>Well, it may close the technical questions but still leave the security
> >>impact unanswered. I would have appreciated a summary of each approach and
> >>explain the pros/cons.
> >This is the most secure way also. In terms of trust between guests and
> >Xen at least. I'm worked with OP-TEE guys mostly, so when I hear about
> >"security", my first thoughts are "Can TEE OS trust to XEN as a
> >mediator? Can TEE client trust to XEN as a mediator?". And with
> >current approach answer is "yes, they can, especially if XEN is a part
> >of a chain of trust".
> >
> >But you probably wanted to ask "Can guest compromise whole system by
> >using TEE mediator or TEE OS?". This is an interesting question.
> >First let's discuss requirements for a TEE mediator. So, mediator
> >should be able to:
> >
> >  * Receive request to handle trapped SMC. This request should include
> >user registers + some information about guest (at least domain id).
> >  * Pin/unpin domain memory pages.
> >  * Map domain memory pages into own address space with RW access.
> >  * Issue real SMC to a TEE.
> >  * Receive information about guest creation and destruction.
> >  * (Probably) inject IRQs into a domain (this can be not a requester domain,
> >but some other domain, that also called to TEE).
> >
> >This is a minimal list of requirements. I think, this should be enough to
> >implement mediator for OP-TEE. But I can't say for sure for other TEEs.
> >
> >Let's consider possible approaches:
> >
> >1. Mediator right in XEN, works at EL2.
> >Pros:
> > * Mediator can use all XEN APIs
> > * As mediator resides in XEN, it can be checked together with XEN
> >   for a validity (trusted boot).
> > * Mediator is initialized before Dom0. Dom0 can work with a TEE.
> > * No extra context switches, no special ABI between XEN and mediator.
> >
> >Cons:
> > * Because it lives in EL2, it can compromise whole hypervisor,
> >   if there is a security bug in mediator code.
> > * No support for closed source TEEs.
> 
> Another cons is you assume TEE API is fully stable and will not change.
> Imagine a new function is added, or a vendor decided to hence with a new set
> of API. How will you know Xen is safe to use it?
With whitelisting, as you correctly suggested below. XEN will process
only know requests. Anything that looks unfimiliar should be rejected.

> 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.

> >
> >2. Mediator in a stubdomain. Works at EL1.
> >Pros:
> > * Mediator is isolated from hypervisor (but it still can do potentially
> >   dangerous things like mapping domain memory or pining pages).
> > * One can legally create and use mediator for a closed-source TEE.
> 
>* Easier to upgrade to a new version of OP-TEE.
Yes, this is true. But what about interface between XEN and mediator?
This is a new entity that should be maintained. Will I abe able to use
new XEN with old mediator? Or new mediator with old XEN?

> >> Cons:
> > * Overhead in XEN<->Mediator communication.
> > * XEN needs to be modified to boot mediator domain before Dom0.
> 
> Is it a really cons? In the past, we had discussion to allow Xen creating
> multiple domain, avoiding the overhead of Dom0. This could also benefits
> here.
As I understand, this is a significant change in XEN. What are the chances,
that community will accept this change? As I can see, immediate benefit
of this is only TEE mediator support. Looks like no one except us
interested in this topic.

BTW, I checked "Xen 

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

[Tamas K Lengyel]

>> In previous discussion we considered only two variants: in XEN or outside
>> XEN. Stubdomain approach looks more secure, but I'm not sure that it is
>> true.
>> Such stubdomain will need access to all guests memory. If you managed to
>> gain control on mediator stubdomain, you can do anything you want with all
>> guests.
>
>
> That's slightly untrue. The stubdomain will only be able to mess with
> domains using TEE.

Would it be feasible to have multiple TEE stubdoms providing the
interface for select domUs (with XSM)? IMHO that would provide the
greatest disaggregation and thus the most security.

Tamas

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

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

[Julien Grall]

Hi Volodymyr,

On 17/10/17 16:59, Volodymyr Babchuk wrote:

On Mon, Oct 16, 2017 at 01:00:21PM +0100, Julien Grall wrote:



On 11/10/17 20:01, Volodymyr Babchuk wrote:

Hello all,


Hi Volodymyr,

Hi Julien




I want to present TEE mediator, that was discussed earlier ([1]).

I selected design with built-in mediators. This is easiest way,
it removes many questions, it is easy to implement and maintain
(at least I hope so).


Well, it may close the technical questions but still leave the security
impact unanswered. I would have appreciated a summary of each approach and
explain the pros/cons.

This is the most secure way also. In terms of trust between guests and
Xen at least. I'm worked with OP-TEE guys mostly, so when I hear about
"security", my first thoughts are "Can TEE OS trust to XEN as a
mediator? Can TEE client trust to XEN as a mediator?". And with
current approach answer is "yes, they can, especially if XEN is a part
of a chain of trust".

But you probably wanted to ask "Can guest compromise whole system by
using TEE mediator or TEE OS?". This is an interesting question.
First let's discuss requirements for a TEE mediator. So, mediator
should be able to:

  * Receive request to handle trapped SMC. This request should include
user registers + some information about guest (at least domain id).
  * Pin/unpin domain memory pages.
  * Map domain memory pages into own address space with RW access.
  * Issue real SMC to a TEE.
  * Receive information about guest creation and destruction.
  * (Probably) inject IRQs into a domain (this can be not a requester domain,
but some other domain, that also called to TEE).

This is a minimal list of requirements. I think, this should be enough to
implement mediator for OP-TEE. But I can't say for sure for other TEEs.

Let's consider possible approaches:

1. Mediator right in XEN, works at EL2.
Pros:
 * Mediator can use all XEN APIs
 * As mediator resides in XEN, it can be checked together with XEN
   for a validity (trusted boot).
 * Mediator is initialized before Dom0. Dom0 can work with a TEE.
 * No extra context switches, no special ABI between XEN and mediator.

Cons:
 * Because it lives in EL2, it can compromise whole hypervisor,
   if there is a security bug in mediator code.
 * No support for closed source TEEs.


Another cons is you assume TEE API is fully stable and will not change. 
Imagine a new function is added, or a vendor decided to hence with a new 
set of API. How will you know Xen is safe to use it?


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.


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.




2. Mediator in a stubdomain. Works at EL1.
Pros:
 * Mediator is isolated from hypervisor (but it still can do potentially
   dangerous things like mapping domain memory or pining pages).
 * One can legally create and use mediator for a closed-source TEE.


   * Easier to upgrade to a new version of OP-TEE.


> Cons:
 * Overhead in XEN<->Mediator communication.
 * XEN needs to be modified to boot mediator domain before Dom0.


Is it a really cons? In the past, we had discussion to allow Xen 
creating multiple domain, avoiding the overhead of Dom0. This could also 
benefits here.



 * Some extra entity required to check validity of a mediator.

3. Mediator in an EL0 app.
The same pros and cons as for mediator in a stubdomain + extra code for EL0
apps, which is needed to be supported and maintained.

Now, back to security questions. There are two possible attacks:
attack at XEN and attack at TEE itself.

If your TEE is vulnerable, then your whole system is compromised anyways.
AFAIK, this approach was used to hack Samsung phones. Some flaw in Qualcom's
TZ implementation.

If your TEE mediator is vulnerable, then your hypervisor and all guests are
compromised. Yes TEE mediator increases attack surface, but the same does
any other XEN<->Guest interface. TEE mediators are expected to be simple
and straightforward, without complex logic. So, I think that they are not
more dangerous than vGIC driver or PL011 emulator.


To be honest when I read the list that a mediator should be able to do, 
I don't think it is possible to say it will not have complex logic.


For instance, for memory pinning. You need to know the buffers which 
likely means introspection of the calls if there are nested buffers.


This implies that you may tie into a specific version of TEE for a 
specific version of Xen.


So how do you expect OP-TEE evolving with Xen support? For example, if 

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

[Volodymyr Babchuk]

On Mon, Oct 16, 2017 at 01:00:21PM +0100, Julien Grall wrote:
> 
> 
> On 11/10/17 20:01, Volodymyr Babchuk wrote:
> >Hello all,
> 
> Hi Volodymyr,
Hi Julien
> 
> >
> >I want to present TEE mediator, that was discussed earlier ([1]).
> >
> >I selected design with built-in mediators. This is easiest way,
> >it removes many questions, it is easy to implement and maintain
> >(at least I hope so).
> 
> Well, it may close the technical questions but still leave the security
> impact unanswered. I would have appreciated a summary of each approach and
> explain the pros/cons.
This is the most secure way also. In terms of trust between guests and
Xen at least. I'm worked with OP-TEE guys mostly, so when I hear about
"security", my first thoughts are "Can TEE OS trust to XEN as a
mediator? Can TEE client trust to XEN as a mediator?". And with
current approach answer is "yes, they can, especially if XEN is a part
of a chain of trust".

But you probably wanted to ask "Can guest compromise whole system by
using TEE mediator or TEE OS?". This is an interesting question.
First let's discuss requirements for a TEE mediator. So, mediator
should be able to:

 * Receive request to handle trapped SMC. This request should include
   user registers + some information about guest (at least domain id).
 * Pin/unpin domain memory pages.
 * Map domain memory pages into own address space with RW access.
 * Issue real SMC to a TEE.
 * Receive information about guest creation and destruction.
 * (Probably) inject IRQs into a domain (this can be not a requester domain,
   but some other domain, that also called to TEE).

This is a minimal list of requirements. I think, this should be enough to
implement mediator for OP-TEE. But I can't say for sure for other TEEs.

Let's consider possible approaches:

1. Mediator right in XEN, works at EL2.
   Pros:
* Mediator can use all XEN APIs
* As mediator resides in XEN, it can be checked together with XEN
  for a validity (trusted boot).
* Mediator is initialized before Dom0. Dom0 can work with a TEE.
* No extra context switches, no special ABI between XEN and mediator.

   Cons:
* Because it lives in EL2, it can compromise whole hypervisor,
  if there is a security bug in mediator code.
* No support for closed source TEEs.

2. Mediator in a stubdomain. Works at EL1.
   Pros:
* Mediator is isolated from hypervisor (but it still can do potentially
  dangerous things like mapping domain memory or pining pages).
* One can legally create and use mediator for a closed-source TEE.

   Cons:
* Overhead in XEN<->Mediator communication.
* XEN needs to be modified to boot mediator domain before Dom0.
* Some extra entity required to check validity of a mediator.

3. Mediator in an EL0 app.
   The same pros and cons as for mediator in a stubdomain + extra code for EL0
   apps, which is needed to be supported and maintained.

Now, back to security questions. There are two possible attacks:
attack at XEN and attack at TEE itself.

If your TEE is vulnerable, then your whole system is compromised anyways.
AFAIK, this approach was used to hack Samsung phones. Some flaw in Qualcom's
TZ implementation.

If your TEE mediator is vulnerable, then your hypervisor and all guests are
compromised. Yes TEE mediator increases attack surface, but the same does
any other XEN<->Guest interface. TEE mediators are expected to be simple
and straightforward, without complex logic. So, I think that they are not
more dangerous than vGIC driver or PL011 emulator.

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. This feature is not implemented in this RFC only because
currently only Dom0 calls are supported.

> This would help to understand that maybe it is an easy way but also still
> secure...
In previous discussion we considered only two variants: in XEN or outside
XEN. Stubdomain approach looks more secure, but I'm not sure that it is true.
Such stubdomain will need access to all guests memory. If you managed to
gain control on mediator stubdomain, you can do anything you want with all
guests.

> 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?

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

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

[Julien Grall]

On 11/10/17 20:01, Volodymyr Babchuk wrote:

Hello all,


Hi Volodymyr,



I want to present TEE mediator, that was discussed earlier ([1]).

I selected design with built-in mediators. This is easiest way,
it removes many questions, it is easy to implement and maintain
(at least I hope so).


Well, it may close the technical questions but still leave the security 
impact unanswered. I would have appreciated a summary of each approach 
and explain the pros/cons.


This would help to understand that maybe it is an easy way but also 
still secure...


To be clear, this series don't look controversial at least for OP-TEE. 
What I am more concerned is about DomU supports.


Cheers,

--
Julien Grall

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