So to get started with the IOCTL's needed between TEE clients in user space and the generic driver. Have the different use cases in back of your mind when thinking about this.
Here are three IOC's needed. What else?
IOCTL's: TEE_IOC_CMD TEE_IOC_SHM_ALLOC TEE_IOC_SHM_FREE
TEE_IOC_SHM_FREE seems not necessary, if we consider that the SHM is by construction a fd-derived object. 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.
Regards, jm
-----Original Message----- From: tee-dev-bounces@lists.linaro.org [mailto:tee-dev-bounces@lists.linaro.org] On Behalf Of Joakim Bech Sent: Friday, March 06, 2015 11:38 AM To: tee-dev Subject: [Tee-dev] IOCTLs for user space and the generic driver
So to get started with the IOCTL's needed between TEE clients in user space and the generic driver. Have the different use cases in back of your mind when thinking about this.
Here are three IOC's needed. What else?
IOCTL's: TEE_IOC_CMD TEE_IOC_SHM_ALLOC TEE_IOC_SHM_FREE
-- Regards, Joakim B
_______________________________________________ Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
Hi Joakim,
On 06.03.2015 12:38, Joakim Bech wrote:
So to get started with the IOCTL's needed between TEE clients in user space and the generic driver. Have the different use cases in back of your mind when thinking about this.
Here are three IOC's needed. What else?
IOCTL's: TEE_IOC_CMD TEE_IOC_SHM_ALLOC TEE_IOC_SHM_FREE
I would also like to add something like TEE_IOC_MEM_MAP TEE_IOC_MEM_UNMAP
They would be use in the case of creating a mapping of a pointer from the CA. Something like creating a scatter list for some random memory inside the calling CA.
Valentin
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.
Regards, jm
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
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?
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?
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.
(*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.
(*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.
Regards, jm
-- Regards, Joakim B
Best, Javier
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
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
Hi Javier,
"TEE_IOC_SHM_FREE" was for me not useful if we consider the case where TEE_IOC_SHM_ALLOC was a case where the allocated piece of memory should be mapped in the user client addressing space through a mmap call and a fd (dma_buf base for example) returned by the ioctl(TEE_IOC_CMD) call. In this case, a simple call of close(fd) was sufficient to call the associated release function to free the associated resources. GP point of view, a SHM is not really a protected/monitored piece of memory (as for the Intel SGX's enclaves). This is just a "public/unsecure" memory chunk which should be accessible by the trusted domain (TEE).
To complete my understanding of your TEE_IOC_xxx proposal, can you elaborate the case where you need to use the TEE_IOC_MEM_MAP? Is it a case where an untrusted client performs a request to the secure domain TEE (not specially a GP TEE) to map a protected/monitored chunk (previously defined by the call of the TEE_IOC_SHM_ALLOC) inside the client addressing space.
TEE_IOC_CMD? Do you consider that the scope of this ioctl is the session opened by the TEE_IOC_OPEN or also the opened TEE device (open("/dev/xxx")?
Best, Jean-Michel
-----Original Message----- From: Javier González [mailto:javigon.napster@gmail.com] Sent: Monday, March 09, 2015 2:34 PM To: Joakim Bech Cc: Jean-michel DELORME; tee-dev Subject: Re: [Tee-dev] IOCTLs for user space and the generic driver
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
Hi Javier, On 09.03.2015 15:33, Javier González wrote:
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.
I don't think this is thing that should be implemented by TEE(or TrustZone). Others have tried to implement such things but they are quite horrible to do with TrustZone. ARM does provide a nice trap mechanism in hyp mode but I think it should be out of scope for us.
What I would like the MAP/UNMAP ioctl to be used is to map pointers from Linux user space to TEE. More or less this is a requirement from GP as well.
Valentin
Hi Valentin,
On Tue, Mar 10, 2015 at 09:53:50AM +0200, Valentin Manea wrote:
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
[...]
What I would like the MAP/UNMAP ioctl to be used is to map pointers from Linux user space to TEE. More or less this is a requirement from GP as well.
Why are these needed? If secure world need this, it could be notified via some callback attached to TEE_IOC_SHM_ALLOC/TEE_IOC_SHM_FREE instead.
Regards, Jens
Hi Jens On 10.03.2015 15:55, Jens Wiklander wrote:
Hi Valentin,
What I would like the MAP/UNMAP ioctl to be used is to map pointers from Linux user space to TEE. More or less this is a requirement from GP as well.
Why are these needed? If secure world need this, it could be notified via some callback attached to TEE_IOC_SHM_ALLOC/TEE_IOC_SHM_FREE instead.
I think these would be needed for TEEC_RegisterSharedMemory(), where client would like to share some of it's own memory(even stack) to TEE, and this call would register the memory to TEE or at least to Linux driver.
Valentin
Hi all,
Jean-Michel:
"TEE_IOC_SHM_FREE" was for me not useful if we consider the case where TEE_IOC_SHM_ALLOC was a case where the allocated piece of memory should be mapped in the user client addressing space through a mmap call and a fd (dma_buf base for example) returned by the ioctl(TEE_IOC_CMD) call. In this case, a simple call of close(fd) was sufficient to call the associated release function to free the associated resources. GP point of view, a SHM is not really a protected/monitored piece of memory (as for the Intel SGX's enclaves). This is just a "public/unsecure" memory chunk which should be accessible by the trusted domain (TEE).
Agreed for SHM. It is just a pice of memory where an untrusted application (UA) can communicate with a TA. Still, I think that this memory should at least count on common process isolation guarantees. This is, it is unsecure as you mention, but not public.
Regarding TEE_IOC_SHM_FREE, I believe that an UA should have the mechanisms to release a piece of shared memory without closing communication with a TA. If anything else to leave developers the possibility to optimise ressource utilization.
Concerning TEE_IOC_CMD vs. functionality in specific operations (e.g., TEE_IOC_SHM_ALLOC), I guess my point is that memory allocation is a general enough operation as to not be done through a command. The most clear line I can draw to discern which functionality gets an operation and which is implemented through a command is the following: Meta-operations that are needed to implement specific behaviour should have an operations; be it ioctl or posix operations (e.g., open, close, memory alloccation). TEE-specific behaviour should be implemented through commands (e.g., TEE_CHECK_INTEGRITY, TEE_STORE_KEY).
To complete my understanding of your TEE_IOC_xxx proposal, can you elaborate the case where you need to use the TEE_IOC_MEM_MAP? Is it a case where an untrusted client performs a request to the secure domain TEE (not specially a GP TEE) to map a protected/monitored chunk (previously defined by the call of the TEE_IOC_SHM_ALLOC) inside the client addressing space.
My idea for TEE_IOC_MEM_MAP (which varies rom Valentin’s vision, as you can see below) is in line with secure memory enclaves (SGX-style). As I answer to Valentin, I am happy to leave this functionality to future revisions of the driver, since it is complex and very specific. See below for Valentin’s proposal for MAP/UMAP.
I think still that TEE_IOC_SHM_ALLOC is necessary to allow untrusted applications (UA) to request a piece of shared memory to interact with a TA.
TEE_IOC_CMD? Do you consider that the scope of this ioctl is the session opened by the TEE_IOC_OPEN or also the opened TEE device (open("/dev/xxx”)?
As mentioned above, open/close are meta-operations, thus I consider they should be implemented through an operation of their own. Posix operations are good to me.
Valentin:
I don't think this is thing that should be implemented by TEE(or TrustZone). Others have tried to implement such things but they are quite horrible to do with TrustZone. ARM does provide a nice trap mechanism in hyp mode but I think it should be out of scope for us.
Point taken. Let us focus on basic functionality and look into this in the future.
What I would like the MAP/UNMAP ioctl to be used is to map pointers from Linux user space to TEE. More or less this is a requirement from GP as well.
+1
Best, Javier
On 9 Mar 2015, at 17:37, Jean-michel DELORME jean-michel.delorme@st.com wrote:
Hi Javier,
"TEE_IOC_SHM_FREE" was for me not useful if we consider the case where TEE_IOC_SHM_ALLOC was a case where the allocated piece of memory should be mapped in the user client addressing space through a mmap call and a fd (dma_buf base for example) returned by the ioctl(TEE_IOC_CMD) call. In this case, a simple call of close(fd) was sufficient to call the associated release function to free the associated resources. GP point of view, a SHM is not really a protected/monitored piece of memory (as for the Intel SGX's enclaves). This is just a "public/unsecure" memory chunk which should be accessible by the trusted domain (TEE).
To complete my understanding of your TEE_IOC_xxx proposal, can you elaborate the case where you need to use the TEE_IOC_MEM_MAP? Is it a case where an untrusted client performs a request to the secure domain TEE (not specially a GP TEE) to map a protected/monitored chunk (previously defined by the call of the TEE_IOC_SHM_ALLOC) inside the client addressing space.
TEE_IOC_CMD? Do you consider that the scope of this ioctl is the session opened by the TEE_IOC_OPEN or also the opened TEE device (open("/dev/xxx")?
Best, Jean-Michel
-----Original Message----- From: Javier González [mailto:javigon.napster@gmail.com] Sent: Monday, March 09, 2015 2:34 PM To: Joakim Bech Cc: Jean-michel DELORME; tee-dev Subject: Re: [Tee-dev] IOCTLs for user space and the generic driver
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
On Tue, Mar 10, 2015 at 05:00:24PM +0200, Valentin Manea wrote:
On 10.03.2015 15:55, Jens Wiklander wrote:
What I would like the MAP/UNMAP ioctl to be used is to map pointers from Linux user space to TEE. More or less this is a requirement from GP as well.
Why are these needed? If secure world need this, it could be notified via some callback attached to TEE_IOC_SHM_ALLOC/TEE_IOC_SHM_FREE instead.
I think these would be needed for TEEC_RegisterSharedMemory(), where client would like to share some of it's own memory(even stack) to TEE, and this call would register the memory to TEE or at least to Linux driver.
Thanks, I didn't think of that.
Regards, Jens
-
Javier González -
Jean-michel DELORME -
Jens Wiklander -
Joakim Bech -
Valentin Manea