Hi,
On 6 Mar 2015, at 03:58, Joakim Bech joakim.bech@linaro.org wrote: On Fri, Mar 06, 2015 at 11:53:44AM +0100, Jean-michel DELORME wrote:
TEE_IOC_SHM_FREE seems not necessary, if we consider that the SHM is by construction a fd-derived object.
So, you are saying that having a single TEE_IOC_SHM is enough and that you could similarly to cmd, just provide another parameter telling what type of shared memory operation it is?
If a generic TEE_IOC_CMD is defined to support the create context, open session, invoke command .. what is the need to have a specific TEE_IOC_SHM_ALLOC command.
I believe that shared memory management is something that is suitable to have in the generic driver. Me and Jens had a rather long discussion about this. We discussed a few alternatives and design choices.
- Specific driver tells what kind of memory it needs when registering to the generic driver. For example, I believe you have some range limits for shared memory in LX? This is an example of information that could be provided when registering.
- We talked about having the possibility to register so that shared memory could be handled in the specific driver in case a certain driver have special needs. However we didn't believe that this was something that was likely to happen.
- We talked about having all shared memory handling done by the specific driver, but then we also thought that the generic driver would be almost pointless(*) and then we're back to square one.
(*) Meaning that we're only looking at this from an OP-TEE point of view. Javier and Valentin have been and are providing more use cases for us.
I guess this is the first point of discussion. When we designed our generic driver we looked at both extremes in de space:(i) open/close/send, where all commands are abstracted, and (ii) a complete interface where all commands have a homolog operation that is exposed.
I have been a supporter of (i), but I can see that general operations such as allocating and mapping memory, which are framework-agnostic, make sense in the interface. I would then say:
TEE_IOC_OPEN TEE_IOC_CLOSE TEE_IOC_CMD TEE_IOC_SHM_ALLOC TEE_IOC_SHM_FREE // Jean-Michel, can you develop on this ioctl? TEE_IOC_MEM_MAP TEE_IOC_MEM_UNMAP // Same as TEE_IOC_SHM_FREE TEE_IOC_TASK // (*1) TEE_IOC_LOAD_TS // Load trusted service (*2) TEE_IOC_GET_TS_LIST // Get trusted service list (*3)
These ioctls should map to a similar interface in the kernel that is available to kernel submodules too.
(*1) In a normal scenario a TEE client will do open - [CMD,SHM,MMAP]* - close. This means that state must be maintained by the client. Some use cases we have been considering follow open - cmd - close, so having an operation that contains this would be useful to free the client from saving the state. I have no strong feelings about this, but since we are discussing, here it is. Use cases include storing a key or verifying the integrity of a component.
(*2) Allows to install a new trusted service.
(*3) We need a mechanism for the TEE to hand in a list of supported trusted services (i.e., commands). Again, TrustZone is very much open, so defining a generic specification is difficult. I am not sure what the best approach is, but the solution we choose should be expressed in the ioctl for TEE clients to know which trusted services they can use. Here, one thing we thought about was naming TEE APIs and inform clients about the ones supported in the TEE. For example, GP_TEEv.1.1 would describe Global Platform v1.1. Another possibility would be to have this information in the device tree (or secure device tree as we discussed with Greg Bellows). We can tackle this in future discussions.
Regards, jm
-- Regards, Joakim B
Best, Javier
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev