Hi Joakim,
On 09 Mar 2015, at 08:35, Joakim Bech joakim.bech@linaro.org wrote:
Hi Javier,
On Fri, Mar 06, 2015 at 04:55:15PM -0800, Javier González wrote: 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
For these two, are you thinking about opening something else than just the device (/dev/xyz)? For the device itself, I people will be using POSIX open and close. Do you have an example where the two IOC's above would be used?
I am thinking of simply initializing the structures that create a session with the TEE. POSIX should be fine too.
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
Related to my previous comment. How does this differ in use case compared to the traditional syscall mmap?
I am thinking of allocating a piece of memory that is protected/monitored from within the TEE; something similar to Intel SGX's trusted enclaves. This is part of what we have been researching. Since the mechanisms to implement this require a form of trap-and-emulate memory operations, which TrustZone alone does not cover today (we need a common MMU), we could start by using mmap and add advanced functionality like this in the future.
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
(*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.
I'm sorry, but I don't think I fully understand your discussion here. Are you basically saying that TEE_IOC_TASK is something that could be used in a stateless fashion? I.e, just invoke a trusted service, in a fire and forget fashion? If yes, then yes, there could be use cases where this is useful.
That is exactly what I mean :)
(*2) Allows to install a new trusted service.
In OP-TEE today this is done automatically. I.e, you provide a uuid for a Trusted Application and then using RPC that particular TA will be loaded automatically. It might make sense to have an explicit IOC for this. However I cannot figure out how that should be used from OP-TEE point of view, but this doesn't rule out that it's something that could be needed in other setups.
I guess the idea is to allow installing a TA at run-time. How each individual TEE instance images this might vary since the TA should be verified, loaded, checked for integrity, etc.
In relation to this, it would make sense to have an io to for remote attestation of a TA, but I'm not sure we are there quite yet.
(*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.
Yes, this one is tricky. Neither do I have a good solution to it. I think it would be pretty easy for us to return a list of uuid's currently supported (in runtime). But those are just random gibberish numbers. One way around it would be to make the uuid somewhat defined. I.e, make certain parts of the uuid indicate that certain functionality could be expected. We are free to propose something.
We should then have a discussion about this. I think the added value of such common set of commands is very high in the context of a generic interface.
Best, Javier.
Regards, jm
-- Regards, Joakim B
Best, Javier
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
-- Regards, Joakim B