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
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
