Hi,
First email on this newly created list. Hopefully everyone receives this email.
So, during the call we had last week we decided to focus on finding the necessary interfaces between user space and the kernel driver(s).
Just to get some kind of nomenclature I suggest: - user space client: The one communicating with the kernel driver. - generic driver: The one communicating with both user space and the specific driver. - specific driver: The one communicating with the generic driver and secure monitor.
I.e: user space client <-> generic driver <-> specific driver <-> monitor
The suggestion from me and Jens is as depicted in [1] and this is based on the feedback we have had from all of you. Our suggestion basically says that you will use 4 different syscalls from user space to the kernel.
open: Obviously needed to be able to talk with the device. Corresponds to: file_operations.open(...)
close: Same here, needed. Corresponds to: file_operations.release(...)
cmd: This is a generic "cmd" instead of having specific GlobalPlatform commands. Which means that it's up to user space client to encapsulate eventual sub-command for the TEE solution it communicates with. For example GlobalPlatforms context, session etc, invoke command are more or less GP specific. Corresponds to: file_operations.unlocked_ioctl(...)
mmap: Since you need to map memory. Corresponds to: file_operations.mmap(...)
The generic driver implements the file_operations stated above. It also exports a shared memory functions to be used by specific drivers in the Linux kernel and from user space clients.
What is happening in the specific driver is implementation defined. Just to give some example we have put down what would be needed in OP-TEE.
The idea was also to only expose one device (the generic driver). But that wouldn't be visible until the specific driver(s) has been loaded. So, when the probe is being called in the specific driver, it registers itself to the generic driver and then the generic driver will register the miscdevice so that user space clients can open the communication with the driver.
In the image [1], we have also shown tee-supplicant. That is mostly to show that this is just another client talking to a TEE. What is happening is implementation defined and it's up to user space and the specific driver to implement a feature like that.
So, what do you say, what is your initial feedback?
[1] https://drive.google.com/file/d/0B21cwcg8lOaJMWRmN05qUXVBSkk/view
Hello Joakim,
Thanks for this clear proposal.
This is not a global feedback, but just a specific point that first raise to my mind: As I understand, you want to set up a generic driver which would be independant of GP api. You propose to push all related GP encapsulation to user land, but some stuff must be done at kernel side (retrieve physical address of shm, cache management, ...). So if a follow your mind, this may be done in the specific driver. Is that ? Is yes, that mean this this today factorized code shared to and use by the tz specific module and the st specific core module could be duplicated. Sure, we could imagine to have another modules to handle GP specificities shared by GP specific modules, but ... I don't know. Perhaps we (?) have to draw all (known) use cases with your design proposal. And perhaps also do the exercise with other proposal, as having two (+) modules exposed to user side: a GP one, and a x one. I suppose we have to maturate all that.
Cheers Manu
-----Original Message----- From: tee-dev-bounces@lists.linaro.org [mailto:tee-dev-bounces@lists.linaro.org] On Behalf Of Joakim Bech Sent: jeudi 5 mars 2015 09:18 To: tee-dev Subject: [Tee-dev] Interface proposal
Hi,
First email on this newly created list. Hopefully everyone receives this email.
So, during the call we had last week we decided to focus on finding the necessary interfaces between user space and the kernel driver(s).
Just to get some kind of nomenclature I suggest: - user space client: The one communicating with the kernel driver. - generic driver: The one communicating with both user space and the specific driver. - specific driver: The one communicating with the generic driver and secure monitor.
I.e: user space client <-> generic driver <-> specific driver <-> monitor
The suggestion from me and Jens is as depicted in [1] and this is based on the feedback we have had from all of you. Our suggestion basically says that you will use 4 different syscalls from user space to the kernel.
open: Obviously needed to be able to talk with the device. Corresponds to: file_operations.open(...)
close: Same here, needed. Corresponds to: file_operations.release(...)
cmd: This is a generic "cmd" instead of having specific GlobalPlatform commands. Which means that it's up to user space client to encapsulate eventual sub-command for the TEE solution it communicates with. For example GlobalPlatforms context, session etc, invoke command are more or less GP specific. Corresponds to: file_operations.unlocked_ioctl(...)
mmap: Since you need to map memory. Corresponds to: file_operations.mmap(...)
The generic driver implements the file_operations stated above. It also exports a shared memory functions to be used by specific drivers in the Linux kernel and from user space clients.
What is happening in the specific driver is implementation defined. Just to give some example we have put down what would be needed in OP-TEE.
The idea was also to only expose one device (the generic driver). But that wouldn't be visible until the specific driver(s) has been loaded. So, when the probe is being called in the specific driver, it registers itself to the generic driver and then the generic driver will register the miscdevice so that user space clients can open the communication with the driver.
In the image [1], we have also shown tee-supplicant. That is mostly to show that this is just another client talking to a TEE. What is happening is implementation defined and it's up to user space and the specific driver to implement a feature like that.
So, what do you say, what is your initial feedback?
[1] https://drive.google.com/file/d/0B21cwcg8lOaJMWRmN05qUXVBSkk/view
-- Regards, Joakim B
_______________________________________________ Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
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
Cheers,
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
Hello Valentin,
On Thu, Mar 5, 2015 at 12:27 PM, Valentin Manea valentin.manea@huawei.com wrote:
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?)
[...]
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.
OK, this make sense. Among non-GP operations that would have to go through the driver, there's also the loading of TA binaries for instance. Still, my point is: can we try to define the operations (i.e., ioctls essentially) as precisely as we can, so that user space code is as simple and portable (on different TEEs with the same generic driver) as possible? We would define all GP operations (create session, invoke command...) plus what's needed to support them (helpers for secure storage, TA loading, shared memory management...). We would still allow private commands to go through the generic driver to the specific backend.
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.
Good idea. Please send me some names in PM. I can contact them and suggest they join the list.
Hi all,
Thanks Joakim for setting the mailing list up :)
My vision of the driver lines up with Valentin’s. I will give a general description; we can get into details as we start agreeing on some basic design aspects.
I support a generic interface that abstracts different tee drivers underneath it and APIs above it. I agree in that we should have a well-defined common ioctl structure to make specific drivers comply with it. The ioctl maps then to an in-kernel common interface. This allows to have (i) a user space GP API implementation that uses the ioctl interface, as well as other components and interfaces (e.g., tee-supplicant); and (ii) kernel submodules directly using the in-kernel interface to which the generic ioctl maps. Examples of kernel submodules that would benefit from this include IMA and the keyring, which already use TPM for specific sensitive tasks. A generic TrustZone driver in the kernel would even open for a soft-TPM implementation based on TrustZone for ARM devices. This is indeed and examples of a non-GP API that could be supported, also for user space applications. I cannot see other way to expose TrustZone services to kernel submodules, but I am happy to be proven wrong.
In my view, the simpler the common interface is, the better. I also agree that some generic commands should be defined. While we risk that the specific TEE implementation does not implement all these commands, there are some operations that must be there (e.g., open, close, allocate shared memory). Here, I think that the main challenge is that TrustZone services are very scattered among frameworks, which makes functionality difficult to generalize (and at the same time makes GP more attractive). However, the fact that GP's API is limited in use cases and that it has already changed many times (4 if I remember properly) makes it difficult to argue for it being upstream. If we start with a small subset of functionality beyond GP traditional use cases (e.g., trusted storage, integrity measurements, reference monitor (?)) based on our experience, we might be able to have a place to start. What are your thoughts here?
Regarding Joakim’s and Jens’ architecture, I think that it captures the essence of this design. One suggestion I have is also decoupling the platform-specific monitor from the specific driver. In my experience this is challenging, but design-wise, if we could have smc handlers for different platforms available to different tee-specific implementations, it would be ideal. This would also simplify support for some ARMv8 smc calls that need to be issued via pointer access.
Best,
Javier
On 5 Mar 2015, at 04:34, Jerome Forissier jerome.forissier@linaro.org wrote:
Hello Valentin,
On Thu, Mar 5, 2015 at 12:27 PM, Valentin Manea valentin.manea@huawei.com wrote: 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?)
[...] 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.
OK, this make sense. Among non-GP operations that would have to go through the driver, there's also the loading of TA binaries for instance. Still, my point is: can we try to define the operations (i.e., ioctls essentially) as precisely as we can, so that user space code is as simple and portable (on different TEEs with the same generic driver) as possible? We would define all GP operations (create session, invoke command...) plus what's needed to support them (helpers for secure storage, TA loading, shared memory management...). We would still allow private commands to go through the generic driver to the specific backend.
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.
Good idea. Please send me some names in PM. I can contact them and suggest they join the list.
-- Jerome
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
On Thu, Mar 5, 2015 at 4:24 PM, Javier González javigon.napster@gmail.com wrote:
Hi all,
Thanks Joakim for setting the mailing list up :)
My vision of the driver lines up with Valentin’s. I will give a general description; we can get into details as we start agreeing on some basic design aspects.
I support a generic interface that abstracts different tee drivers underneath it and APIs above it. I agree in that we should have a well-defined common ioctl structure to make specific drivers comply with it. The ioctl maps then to an in-kernel common interface. This allows to have (i) a user space GP API implementation that uses the ioctl interface, as well as other components and interfaces (e.g., tee-supplicant); and (ii) kernel submodules directly using the in-kernel interface to which the generic ioctl maps. Examples of kernel submodules that would benefit from this include IMA and the keyring, which already use TPM for specific sensitive tasks. A generic TrustZone driver in the kernel would even open for a soft-TPM implementation based on TrustZone for ARM devices. This is indeed and examples of a non-GP API that could be supported, also for user space applications. I cannot see other way to expose TrustZone services to kernel submodules, but I am happy to be proven wrong.
In my view, the simpler the common interface is, the better. I also agree that some generic commands should be defined. While we risk that the specific TEE implementation does not implement all these commands, there are some operations that must be there (e.g., open, close, allocate shared memory). Here, I think that the main challenge is that TrustZone services are very scattered among frameworks, which makes functionality difficult to generalize (and at the same time makes GP more attractive). However, the fact that GP's API is limited in use cases and that it has already changed many times (4 if I remember properly) makes it difficult to argue for it being upstream. If we start with a small subset of functionality beyond GP traditional use cases (e.g., trusted storage, integrity measurements, reference monitor (?)) based on our experience, we might be able to have a place to start. What are your thoughts here?
ARM describes SMC Calling Convention in http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0028a/index.h.... I think we should focus on covering "Trusted Application Calls" and "Trusted OS Calls" since the rest can very well be managed outside the TEE on some platforms. ARM-TF manages the PSCI interface for instance.
Regarding Joakim’s and Jens’ architecture, I think that it captures the essence of this design. One suggestion I have is also decoupling the platform-specific monitor from the specific driver. In my experience this is challenging, but design-wise, if we could have smc handlers for different platforms available to different tee-specific implementations, it would be ideal. This would also simplify support for some ARMv8 smc calls that need to be issued via pointer access.
What is a "monitor"?
SMCs aren't different on ARMv8 compared to ARMv7, at least from a normal world point of view. Once example where SMCs already are used on ARMv8 is the usage of PSCI.
As Valentin mentioned, we need a standardized way for the specific driver to identify itself (type and version) and probably the same for the Trusted OS too. This can be part of the interface provided by the "common" driver if we require the "specific" driver to supply this information when registering.
Regards, Jens
Hi Jens,
On 06.03.2015 09:43, Jens Wiklander wrote:
What is a "monitor"?
SMCs aren't different on ARMv8 compared to ARMv7, at least from a normal world point of view. Once example where SMCs already are used on ARMv8 is the usage of PSCI.
As Valentin mentioned, we need a standardized way for the specific driver to identify itself (type and version) and probably the same for the Trusted OS too. This can be part of the interface provided by the "common" driver if we require the "specific" driver to supply this information when registering.
I guess Javier was talking about the infamous scm_call() that QC uses http://lxr.free-electrons.com/source/arch/arm/mach-qcom/scm.c#L224 to enter the QSEE. They don't follow ARM calling convention but they invented their own. This was for v7 though, I have no idea about v8.
Valentin
Hi,
For completenes:
What is a "monitor”?
Secure monitor
SMCs aren't different on ARMv8 compared to ARMv7, at least from a normal world point of view. Once example where SMCs already are used on ARMv8 is the usage of PSCI.
As Valentin mentioned, we need a standardized way for the specific driver to identify itself (type and version) and probably the same for the Trusted OS too. This can be part of the interface provided by the "common" driver if we require the "specific" driver to supply this information when registering.
I guess Javier was talking about the infamous scm_call() that QC uses http://lxr.free-electrons.com/source/arch/arm/mach-qcom/scm.c#L224 to enter the QSEE. They don't follow ARM calling convention but they invented their own. This was for v7 though, I have no idea about v8.
Precisely. QCOM, TI, Brcm and newer 64 bit chips do not follow SMC calling convention. If we want to support them we need to abstract the specific driver from the SMC call in it self. This can be future work, but it is worth considering.
As Valentin mentioned, we need a standardized way for the specific driver to identify itself (type and version) and probably the same for the Trusted OS too. This can be part of the interface provided by the "common" driver if we require the "specific" driver to supply this information when registering.
Agreed.
Best, Javier
On 5 Mar 2015, at 23:47, Valentin Manea valentin.manea@huawei.com wrote:
Hi Jens,
On 06.03.2015 09:43, Jens Wiklander wrote:
What is a "monitor"?
SMCs aren't different on ARMv8 compared to ARMv7, at least from a normal world point of view. Once example where SMCs already are used on ARMv8 is the usage of PSCI.
As Valentin mentioned, we need a standardized way for the specific driver to identify itself (type and version) and probably the same for the Trusted OS too. This can be part of the interface provided by the "common" driver if we require the "specific" driver to supply this information when registering.
I guess Javier was talking about the infamous scm_call() that QC uses http://lxr.free-electrons.com/source/arch/arm/mach-qcom/scm.c#L224 to enter the QSEE. They don't follow ARM calling convention but they invented their own. This was for v7 though, I have no idea about v8.
Valentin
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
Hi Manu,
On Thu, Mar 05, 2015 at 10:04:21AM +0100, Emmanuel MICHEL wrote:
Hello Joakim,
Thanks for this clear proposal.
This is not a global feedback, but just a specific point that first raise to my mind: As I understand, you want to set up a generic driver which would be independant of GP api. You propose to push all related GP encapsulation to user land, but some stuff must be done at kernel side (retrieve physical address of shm, cache management, ...). So if a follow your mind, this may be done in the specific driver. Is that ?
Yes, GP code will go into the user space client and the specific driver.
Is yes, that mean this this today factorized code shared to and use by the tz specific module and the st specific core module could be duplicated. Sure, we could imagine to have another modules to handle GP specificities shared by GP specific modules, but ... I don't know.
We should try to avoid code duplication as much as possible. To avoid this happening in specific driver we might end up having to leverage the specific driver from sub-driver also.
Perhaps we (?) have to draw all (known) use cases with your design proposal. And perhaps also do the exercise with other proposal, as having two (+) modules exposed to user side: a GP one, and a x one. I suppose we have to maturate all that.
I'm open for having a use case based discussion. However I'm afraid that we will just end up with a lot of discussions. After reading all responses in this thread yesterday I think we need to start with identifying the needed IOCTL's. Defining the IOCTL's will implicitly require us to think about use cases.
Cheers Manu
Hi Joakim,
I think this could fit everybody's needs On 05.03.2015 10:18, Joakim Bech wrote:
The suggestion from me and Jens is as depicted in [1] and this is based on the feedback we have had from all of you. Our suggestion basically says that you will use 4 different syscalls from user space to the kernel.
open: Obviously needed to be able to talk with the device. Corresponds to: file_operations.open(...)
close: Same here, needed. Corresponds to: file_operations.release(...)
cmd: This is a generic "cmd" instead of having specific GlobalPlatform commands. Which means that it's up to user space client to encapsulate eventual sub-command for the TEE solution it communicates with. For example GlobalPlatforms context, session etc, invoke command are more or less GP specific. Corresponds to: file_operations.unlocked_ioctl(...)
I think to be able to upstream we should define the format of the interface, for example while the actual commands are implementation specific the marshaling should be done in the interface. To be more specific the ioctl structure format should be somewhat common. We should have a fixed way of encoding version of the userspace->kernel interface, maybe the size of the struct and some command ID.
I think this way if we had a upstream interface then it would be easier for each TEE specific part of the driver to be ported to different kernel versions.
Also I wonder if there could be some common commands, like memory allocate or some dma-buff commands?
mmap: Since you need to map memory. Corresponds to: file_operations.mmap(...)
The generic driver implements the file_operations stated above. It also exports a shared memory functions to be used by specific drivers in the Linux kernel and from user space clients.
What is happening in the specific driver is implementation defined. Just to give some example we have put down what would be needed in OP-TEE.
The idea was also to only expose one device (the generic driver). But that wouldn't be visible until the specific driver(s) has been loaded. So, when the probe is being called in the specific driver, it registers itself to the generic driver and then the generic driver will register the miscdevice so that user space clients can open the communication with the driver.
In the image [1], we have also shown tee-supplicant. That is mostly to show that this is just another client talking to a TEE. What is happening is implementation defined and it's up to user space and the specific driver to implement a feature like that.
So, what do you say, what is your initial feedback?
[1] https://drive.google.com/file/d/0B21cwcg8lOaJMWRmN05qUXVBSkk/view
The part looks quite fine to me
Regards, Valentin
Hello Valentine,
Just for me to understand:
" To be more specific the ioctl structure format should be somewhat common. "
Today we use GP interface. With which other api do you want to communize the interface ? Thanks
Cheers Manu
-----Original Message----- From: tee-dev-bounces@lists.linaro.org [mailto:tee-dev-bounces@lists.linaro.org] On Behalf Of Valentin Manea Sent: jeudi 5 mars 2015 10:16 To: Joakim Bech; tee-dev Subject: Re: [Tee-dev] Interface proposal
Hi Joakim,
I think this could fit everybody's needs On 05.03.2015 10:18, Joakim Bech wrote:
The suggestion from me and Jens is as depicted in [1] and this is based on the feedback we have had from all of you. Our suggestion > basically says that you will use 4 different syscalls from user > space to the kernel.
open: Obviously needed to be able to talk with the device. Corresponds to: file_operations.open(...) > > close: Same here, needed. Corresponds to: file_operations.release(...)
cmd: This is a generic "cmd" instead of having specific > GlobalPlatform commands. Which means that it's up to user space > client to encapsulate eventual sub-command for the TEE solution it > communicates with. For example GlobalPlatforms context, session etc, > invoke command are more or less GP specific. Corresponds to: file_operations.unlocked_ioctl(...)
I think to be able to upstream we should define the format of the interface, for example while the actual commands are implementation specific the marshaling should be done in the interface. To be more specific the ioctl structure format should be somewhat common. We should have a fixed way of encoding version of the userspace->kernel interface, maybe the size of the struct and some command ID.
I think this way if we had a upstream interface then it would be easier for each TEE specific part of the driver to be ported to different kernel versions.
Also I wonder if there could be some common commands, like memory allocate or some dma-buff commands?
mmap: Since you need to map memory. Corresponds to: file_operations.mmap(...)
The generic driver implements the file_operations stated above. It > also exports a shared memory functions to be used by specific > drivers in the Linux kernel and from user space clients.
What is happening in the specific driver is implementation defined. Just to give some example we have put down what would be needed in > OP-TEE.
The idea was also to only expose one device (the generic driver). But > that wouldn't be visible until the specific driver(s) has been > loaded. So, when the probe is being called in the specific driver, > it registers itself to the generic driver and then the generic > driver will register the miscdevice so that user space clients can > open the communication with the driver.
In the image [1], we have also shown tee-supplicant. That is mostly > to show that this is just another client talking to a TEE. What is > happening is implementation defined and it's up to user space and the > specific driver to implement a feature like that.
So, what do you say, what is your initial feedback?
[1] https://drive.google.com/file/d/0B21cwcg8lOaJMWRmN05qUXVBSkk/view
The part looks quite fine to me
Regards, Valentin
_______________________________________________ Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
HI Emmanuel, On 05.03.2015 11:37, Emmanuel MICHEL wrote:
Hello Valentine,
Just for me to understand:
" To be more specific the ioctl structure format should be somewhat common."
Today we use GP interface. With which other api do you want to communize the interface ? Thanks
GP is just an API, the binary format is implementation specific. However in the specific case of IOCTLs we are talking about send some binary data from user space to kernel which will forwarded to TEE. Since we are trying to build a common layer I think this should have some comonalities to cover the generic TEEs. I would guess people upstream too would like it more if we didn't just say GP is the only interface.
Valentin
Hi all,
To continue the discussion and to clarify some points in my mind about the objectives to build a common layer or "generic" driver (GP or not) which is a "simple" (should be clarified) way to pass the opaque data to a backend without a real added value.
If we keep the proposed modular design (seems the case today), the "generic" part can be abstract to manage the notions of context, session, command and also shared memory (RPC-like API). This approach is compliant with the GP TEEC API or other API which expects to manage the remote services. Basically, based on the well-defined back-end call back API (with the mandatory and optional methods), the common part will be in-charge to manage the life cycle of the underlying managed objects and the back-ends will be and should be a simple component to implement the specific part.
Expected service from the back-ends: - power management aspect - inter domain memory management (including SHM public management and cache management) - firmware manager - communication agent - API manipulated interface the manage the opaque data (GP specific aspects will be done here)
All these points (design approach) are basically covered by our current solution (GP oriented). We need to remove the GP specific aspects and to move the tee_supplicant services to the back-end.
You share my view or my vision is completely wrong...
Br, Jean-Michel
-----Original Message----- From: tee-dev-bounces@lists.linaro.org [mailto:tee-dev-bounces@lists.linaro.org] On Behalf Of Valentin Manea Sent: Thursday, March 05, 2015 12:15 PM To: Emmanuel MICHEL; tee-dev Subject: Re: [Tee-dev] Interface proposal
HI Emmanuel, On 05.03.2015 11:37, Emmanuel MICHEL wrote:
Hello Valentine,
Just for me to understand:
" To be more specific the ioctl structure format should be somewhat common."
Today we use GP interface. With which other api do you want to communize the interface ? Thanks
GP is just an API, the binary format is implementation specific. However in the specific case of IOCTLs we are talking about send some binary data from user space to kernel which will forwarded to TEE. Since we are trying to build a common layer I think this should have some comonalities to cover the generic TEEs. I would guess people upstream too would like it more if we didn't just say GP is the only interface.
Valentin
_______________________________________________ Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
Hi all,
Thanks Joakim for setting the mailing list up :)
My vision of the driver lines up with Valentin’s. I will give a general description; we can get into details as we start agreeing on some basic design aspects.
I support a generic interface that abstracts different tee drivers underneath it and APIs above it. I agree in that we should have a well-defined common ioctl structure to make specific drivers comply with it. The ioctl maps then to an in-kernel common interface. This allows to have (i) a user space GP API implementation that uses the ioctl interface, as well as other components and interfaces (e.g., tee-supplicant); and (ii) kernel submodules directly using the in-kernel interface to which the generic ioctl maps. Examples of kernel submodules that would benefit from this include IMA and the keyring, which already use TPM for specific sensitive tasks. A generic TrustZone driver in the kernel would even open for a soft-TPM implementation based on TrustZone for ARM devices. This is indeed and examples of a non-GP API that could be supported, also for user space applications. I cannot see other way to expose TrustZone services to kernel submodules, but I am happy to be proven wrong.
In my view, the simpler the common interface is, the better. I also agree that some generic commands should be defined. While we risk that the specific TEE implementation does not implement all these commands, there are some operations that must be there (e.g., open, close, allocate shared memory). Here, I think that the main challenge is that TrustZone services are very scattered among frameworks, which makes functionality difficult to generalize (and at the same time makes GP more attractive). However, the fact that GP's API is limited in use cases and that it has already changed many times (4 if I remember properly) makes it difficult to argue for it being upstream. If we start with a small subset of functionality beyond GP traditional use cases (e.g., trusted storage, integrity measurements, reference monitor (?)) based on our experience, we might be able to have a place to start. What are your thoughts here?
Regarding Joakim’s and Jens’ architecture, I think that it captures the essence of this design. One suggestion I have is also decoupling the platform-specific monitor from the specific driver. In my experience this is challenging, but design-wise, if we could have smc handlers for different platforms available to different tee-specific implementations, it would be ideal. This would also simplify support for some ARMv8 smc calls that need to be issued via pointer access.
Best,
Javier
On 5 Mar 2015, at 03:52, Jean-michel DELORME jean-michel.delorme@st.com wrote:
Hi all,
To continue the discussion and to clarify some points in my mind about the objectives to build a common layer or "generic" driver (GP or not) which is a "simple" (should be clarified) way to pass the opaque data to a backend without a real added value.
If we keep the proposed modular design (seems the case today), the "generic" part can be abstract to manage the notions of context, session, command and also shared memory (RPC-like API). This approach is compliant with the GP TEEC API or other API which expects to manage the remote services. Basically, based on the well-defined back-end call back API (with the mandatory and optional methods), the common part will be in-charge to manage the life cycle of the underlying managed objects and the back-ends will be and should be a simple component to implement the specific part.
Expected service from the back-ends:
- power management aspect
- inter domain memory management (including SHM public management and cache management)
- firmware manager
- communication agent
- API manipulated interface the manage the opaque data (GP specific aspects will be done here)
All these points (design approach) are basically covered by our current solution (GP oriented). We need to remove the GP specific aspects and to move the tee_supplicant services to the back-end.
You share my view or my vision is completely wrong...
Br, Jean-Michel
-----Original Message----- From: tee-dev-bounces@lists.linaro.org [mailto:tee-dev-bounces@lists.linaro.org] On Behalf Of Valentin Manea Sent: Thursday, March 05, 2015 12:15 PM To: Emmanuel MICHEL; tee-dev Subject: Re: [Tee-dev] Interface proposal
HI Emmanuel, On 05.03.2015 11:37, Emmanuel MICHEL wrote:
Hello Valentine,
Just for me to understand:
" To be more specific the ioctl structure format should be somewhat common."
Today we use GP interface. With which other api do you want to communize the interface ? Thanks
GP is just an API, the binary format is implementation specific. However in the specific case of IOCTLs we are talking about send some binary data from user space to kernel which will forwarded to TEE. Since we are trying to build a common layer I think this should have some comonalities to cover the generic TEEs. I would guess people upstream too would like it more if we didn't just say GP is the only interface.
Valentin
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
Hi Jean-Michel,
On Thu, Mar 05, 2015 at 12:52:52PM +0100, Jean-michel DELORME wrote:
Hi all,
To continue the discussion and to clarify some points in my mind about the objectives to build a common layer or "generic" driver (GP or not) which is a "simple" (should be clarified) way to pass the opaque data to a backend without a real added value.
If we keep the proposed modular design (seems the case today), the "generic" part can be abstract to manage the notions of context, session, command and also shared memory (RPC-like API). This approach is compliant with the GP TEEC API or other API which expects to manage the remote services. Basically, based on the well-defined back-end call back API (with the mandatory and optional methods), the common part will be in-charge to manage the life cycle of the underlying managed objects and the back-ends will be and should be a simple component to implement the specific part.
Expected service from the back-ends: - power management aspect - inter domain memory management (including SHM public management and cache management) - firmware manager - communication agent - API manipulated interface the manage the opaque data (GP specific aspects will be done here)
All these points (design approach) are basically covered by our current solution (GP oriented). We need to remove the GP specific aspects and to move the tee_supplicant services to the back-end.
You share my view or my vision is completely wrong...
I think we can re-use a lot of code in the existing implementation, but I also think that we need to move some parts of the code to the specific driver (backplane) and maybe also move some parts to user space. So, yes, I think that I in general share your vision.
Br, Jean-Michel
Hi all,
From Joakim: We should try to avoid code duplication as much as possible. To avoid this happening in specific driver we might end up having to leverage the specific driver from sub-driver also.
Do you suggest to have another layer, between the "generic" and the "specific"? If so, it should be in the design from the start because we want 2 backend drivers that target optee: one for TZ, one for our specific copro.
From Joakim: I think we can re-use a lot of code in the existing implementation, but I also think that we need to move some parts of the code to the specific driver (backplane) and maybe also move some parts to user space. So,
Having common parts moved from the driver to the user space is not a problem I guess because they remain common. Having common parts moved from the generic driver to the specific one is quite odd... apart if we add this new layer.
From the discussion on smc: One suggestion I have is also decoupling the platform-specific monitor
from the specific driver.
In my experience this is challenging, but design-wise, if we could have
smc handlers for
different platforms available to different tee-specific implementations,
it would be ideal.
This would also simplify support for some ARMv8 smc calls that need to be
issued via pointer access smc handlers are used to jump to TZ. So such a code should *not* be in the "generic" part.
Regards, Pascal.
On 6 March 2015 at 09:54, Joakim Bech joakim.bech@linaro.org wrote:
Hi Jean-Michel,
On Thu, Mar 05, 2015 at 12:52:52PM +0100, Jean-michel DELORME wrote:
Hi all,
To continue the discussion and to clarify some points in my mind about the objectives to build a common layer or "generic" driver (GP or not) which is a "simple" (should be clarified) way to pass the opaque data to a backend without a real added value.
If we keep the proposed modular design (seems the case today), the "generic" part can be abstract to manage the notions of context, session, command and also shared memory (RPC-like API). This approach is compliant with the GP TEEC API or other API which expects to manage the remote services. Basically, based on the well-defined back-end call back API (with the mandatory and optional methods), the common part will be in-charge to manage the life cycle of the underlying managed objects and the back-ends will be and should be a simple component to implement the specific part.
Expected service from the back-ends: - power management aspect - inter domain memory management (including SHM public management and cache management) - firmware manager - communication agent - API manipulated interface the manage the opaque data (GP specific aspects will be done here)
All these points (design approach) are basically covered by our current solution (GP oriented). We need to remove the GP specific aspects and to move the tee_supplicant services to the back-end.
You share my view or my vision is completely wrong...
I think we can re-use a lot of code in the existing implementation, but I also think that we need to move some parts of the code to the specific driver (backplane) and maybe also move some parts to user space. So, yes, I think that I in general share your vision.
Br, Jean-Michel
-- Regards, Joakim B
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
Hi Pascal,
On Fri, Mar 06, 2015 at 10:18:48AM +0100, Pascal Brand wrote:
Hi all,
From Joakim:
We should try to avoid code duplication as much as possible. To avoid this happening in specific driver we might end up having to leverage the specific driver from sub-driver also.
Do you suggest to have another layer, between the "generic" and the "specific"?
No, this is not what I suggest, I still think having it in two layers is a good separation. However, in case there is a need to separate the specific driver to support more hardware, TEE's etc, then I think we should leave that up to the one implementing the specific driver.
If so, it should be in the design from the start because we want 2 backend drivers that target optee: one for TZ, one for our specific copro.
This is an example where it's up to the specific driver to handle this.
From Joakim:
I think we can re-use a lot of code in the existing implementation, but I also think that we need to move some parts of the code to the specific driver (backplane) and maybe also move some parts to user space. So,
Having common parts moved from the driver to the user space is not a problem I guess because they remain common. Having common parts moved from the generic driver to the specific one is quite odd... apart if we add this new layer.
Why is it odd? If parts are generic, they should stay, if they are not generic, then they don't belong there and needs to be moved "somewhere" and "somewhere" is either user space or the specific driver.
From the discussion on smc:
One suggestion I have is also decoupling the platform-specific monitor from the specific driver. In my experience this is challenging, but design-wise, if we could have smc handlers for different platforms available to different tee-specific implementations, it would be ideal. This would also simplify support for some ARMv8 smc calls that need to be issued via pointer access
smc handlers are used to jump to TZ. So such a code should *not* be in the "generic" part.
+1 regarding SMC not in the generic part, but just as ARM have proposed SMC calling convention it would probably also be good to do the same exercise regards the SMC-calls as we just have started with user space / kernel interface, i.e, what Jens was touching in his response in this mail thread also.
Regards, Pascal.
Hello Joakim,
What is your proposal to deal with the common code with several specific drivers, and can't stand in generic part ?
Regards Manu
-----Original Message----- From: tee-dev-bounces@lists.linaro.org [mailto:tee-dev-bounces@lists.linaro.org] On Behalf Of Joakim Bech Sent: vendredi 6 mars 2015 11:24 To: Pascal Brand Cc: tee-dev Subject: Re: [Tee-dev] Interface proposal
Hi Pascal,
On Fri, Mar 06, 2015 at 10:18:48AM +0100, Pascal Brand wrote:
Hi all,
From Joakim:
We should try to avoid code duplication as much as possible. To avoid this happening in specific driver we might end up having to leverage the specific driver from sub-driver also.
Do you suggest to have another layer, between the "generic" and the "specific"?
No, this is not what I suggest, I still think having it in two layers is a good separation. However, in case there is a need to separate the specific driver to support more hardware, TEE's etc, then I think we should leave that up to the one implementing the specific driver.
If so, it should be in the design from the start because we want 2 backend drivers that target optee: one for TZ, one for our specific copro.
This is an example where it's up to the specific driver to handle this.
From Joakim:
I think we can re-use a lot of code in the existing implementation, but I also think that we need to move some parts of the code to the specific driver (backplane) and maybe also move some parts to user space. So,
Having common parts moved from the driver to the user space is not a problem I guess because they remain common. Having common parts moved from the generic driver to the specific one is quite odd... apart if we add this new layer.
Why is it odd? If parts are generic, they should stay, if they are not generic, then they don't belong there and needs to be moved "somewhere" and "somewhere" is either user space or the specific driver.
From the discussion on smc:
One suggestion I have is also decoupling the platform-specific monitor from the specific driver. In my experience this is challenging, but design-wise, if we could have smc handlers for different platforms available to different tee-specific implementations, it would be ideal. This would also simplify support for some ARMv8 smc calls that need to be issued via pointer access
smc handlers are used to jump to TZ. So such a code should *not* be in the "generic" part.
+1 regarding SMC not in the generic part, but just as ARM have proposed SMC calling convention it would probably also be good to do the same exercise regards the SMC-calls as we just have started with user space / kernel interface, i.e, what Jens was touching in his response in this mail thread also.
Regards, Pascal.
-- Regards, Joakim B
_______________________________________________ Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
Hi Manu,
On Fri, Mar 06, 2015 at 12:33:41PM +0100, Emmanuel MICHEL wrote:
Hello Joakim,
What is your proposal to deal with the common code with several specific drivers, and can't stand in generic part ?
That is something we have to deal with case by case. Do you have a concrete example that we should consider already know?
Regards Manu
Re,
In example, copy parameters from userland, with cache management.
Regards Manu
-----Original Message----- From: Joakim Bech [mailto:joakim.bech@linaro.org] Sent: vendredi 6 mars 2015 12:40 To: Emmanuel MICHEL Cc: tee-dev Subject: Re: [Tee-dev] Interface proposal
Hi Manu,
On Fri, Mar 06, 2015 at 12:33:41PM +0100, Emmanuel MICHEL wrote:
Hello Joakim,
What is your proposal to deal with the common code with several specific drivers, and can't stand in generic part ?
That is something we have to deal with case by case. Do you have a concrete example that we should consider already know?
Regards Manu
-- Regards, Joakim B
Hi Manu,
On Fri, Mar 06, 2015 at 12:45:25PM +0100, Emmanuel MICHEL wrote:
Re,
In example, copy parameters from userland, with cache management.
Do we actually have such a use case? If yes, shouldn't we try to avoid imposing cache management? But I think I'm getting the message that you're trying to tell, i.e, that there are use cases that share functionality, but lives in the gray zone between generic vs specific driver.
If we come to think about such use cases, then I encourage us to bring it up for discussion to decide if it is functionality that could be considered as generic or not. If we decide that it isn't then it has to be something that is handled by the specific driver(s).
So just to hear what others have to say about it, what do you think, is cache management something that is suitable to have in a generic TEE layer?
Regards Manu
-----Original Message----- From: Joakim Bech [mailto:joakim.bech@linaro.org] Sent: vendredi 6 mars 2015 12:40 To: Emmanuel MICHEL Cc: tee-dev Subject: Re: [Tee-dev] Interface proposal
Hi Manu,
On Fri, Mar 06, 2015 at 12:33:41PM +0100, Emmanuel MICHEL wrote:
Hello Joakim,
What is your proposal to deal with the common code with several specific drivers, and can't stand in generic part ?
That is something we have to deal with case by case. Do you have a concrete example that we should consider already know?
Regards Manu
-- Regards, Joakim B
Hello Joakim,
Ok, for delegating cache management to backend.
Regards Manu
-----Original Message----- From: Joakim Bech [mailto:joakim.bech@linaro.org] Sent: lundi 9 mars 2015 13:50 To: Emmanuel MICHEL Cc: tee-dev Subject: Re: [Tee-dev] Interface proposal
Hi Manu,
On Fri, Mar 06, 2015 at 12:45:25PM +0100, Emmanuel MICHEL wrote:
Re,
In example, copy parameters from userland, with cache management.
Do we actually have such a use case? If yes, shouldn't we try to avoid imposing cache management? But I think I'm getting the message that you're trying to tell, i.e, that there are use cases that share functionality, but lives in the gray zone between generic vs specific driver.
If we come to think about such use cases, then I encourage us to bring it up for discussion to decide if it is functionality that could be considered as generic or not. If we decide that it isn't then it has to be something that is handled by the specific driver(s).
So just to hear what others have to say about it, what do you think, is cache management something that is suitable to have in a generic TEE layer?
Regards Manu
-----Original Message----- From: Joakim Bech [mailto:joakim.bech@linaro.org] Sent: vendredi 6 mars 2015 12:40 To: Emmanuel MICHEL Cc: tee-dev Subject: Re: [Tee-dev] Interface proposal
Hi Manu,
On Fri, Mar 06, 2015 at 12:33:41PM +0100, Emmanuel MICHEL wrote:
Hello Joakim,
What is your proposal to deal with the common code with several specific drivers, and can't stand in generic part ?
That is something we have to deal with case by case. Do you have a concrete example that we should consider already know?
Regards Manu
-- Regards, Joakim B
-- Regards, Joakim B
On Thu, Mar 05, 2015 at 10:37:18AM +0100, Emmanuel MICHEL wrote:
Hello Valentine,
Just for me to understand:
" To be more specific the ioctl structure format should be somewhat common. "
Today we use GP interface. With which other api do you want to communize the interface ?
Ultimately the generic driver should be able to be compatible with existing TEE's and TEE's coming in the future. We know that there are quite a few implementations out there, OP-TEE, TLK, OTZ, <t-base-200 and we know that Google, Qualcomm, Intel and Huawei have their own TEE implementations. We don't know exactly how their interfaces will look like, but I don't think we should take for granted that all of them use GP interfaces.
I don't say that we can architect for unknown interfaces, but I still think we could make a quite good guess. I think about this as a "light" version of "syscalls" for TEE's.
Thanks
Cheers Manu
Hi all,
So after reading the responses from all of you and to not end up in (just only) long discussions I'd suggest that we start to identify the IOCTL's needed and how the structure(s) used to pass the data from user space to the kernel should look like. However, just to cut the discussions to a minimum, let's start with just putting the IOC's needed and let's deal with the data later on. Also, I think I will post this as a new thread on the mailing list.
By the way, when speaking about mailing list. If you have the possibility to use an email client with thread view, then I encourage you to consider using it, since it makes much more sense when responding to individual post(s) within the same thread compared to seeing the complete thread in a linear view.
Also regarding this email list. Please note that it is a public list, which means anyone can find it and subscribe to it. I have no problem that it is public, in fact I encourage that people that are interested in taking part of the discussions joins the list. In the end, this is open source we are talking about. But I just want to make you aware of this.
Lastly, the intention with a list like this is _not_ to replace the traditional Linux Kernel Mailing List. This is just a first step for us to smoke out the initial open questions. As soon as we start to send patches to LKML, I'd hope that the discussion will move from here to there instead (at least discussion strictly related to the kernel driver).
On Thu, Mar 05, 2015 at 09:18:09AM +0100, Joakim Bech wrote:
Hi,
First email on this newly created list. Hopefully everyone receives this email.
...
-
Emmanuel MICHEL -
Javier González -
Javier González -
Jean-michel DELORME -
Jens Wiklander -
Jerome Forissier -
Joakim Bech -
Pascal Brand -
Valentin Manea