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