Hi Jerome,
On 05.03.2015 12:19, Jerome Forissier wrote:
Hi all,

I second Emmanuel's concerns. It seems to me that with the current definitions, the generic driver would almost be an empty pipe, and add little value to the solution.

In my opinion, the generic driver has to define a precise interface and not allow opaque commands that would depend on the TEE solution. Otherwise what assumptions can the user space make when it opens the device? Should it probe the driver to detect which language it speaks? Better have one driver for each "language" (GlobalPlatform or whatever).

So I would drop the "generic driver" and focus on a "GlobalPlatform TEE driver". If someone needs to implement a different interface than GP, then he would write another driver (is it something we have to consider short-term?)

Then assuming this is acceptable, the second question is: can this GP driver still be somewhat "generic" in terms of the TEE it supports (i.e., common accross several TEE implementations)? I think it can, if we can properly define the interface between the GP driver and the TEE-specific driver. This interface would be less important than the one with user-space (which is the one that lasts even as kernel versions change). And we need to identify what amount of code we expect to make common -- if it's too little, it's not worth it.

So as a summary: we would have for instance:
- gptee.ko + opteearmtz.ko for OP-TEE with TrustZone
- gptee.ko + optee<xyz>.ko for OP-TEE with another proprietary secure hardware,
- gptee.ko + <othertee>.ko for another TEE implementation 


  If you put it like that I don't see much value in a GP driver and I would guess upstream also wouldn't see value in it anyway, this is the reason I was proposing something more generic. But to give a specific example for my reasons: how do you implement secure storage? In Huawei TEE case there is a secure storage daemon that has a separate channel to TEE - this channel is outside GP specifications completely and it's homebrew.
  This is just one short example, but there enough of these implementation details where just saying we want a GP driver would not be enough and a separate channel would be created between user space and kernel.
  So basically the GP TEE driver would not bring enough value.

PS: I think you are in the same building as the Trustonic guys, maybe inviting them would not be a bad idea - while I wrote most of the driver, I would rather not talk for them.
If you don't know anybody I can suggest a few contacts.

Valentin