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,
--
Jerome
On Thu, Mar 5, 2015 at 10:04 AM, Emmanuel MICHEL
emmanuel.michel@st.com
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 ?
> 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
>
> _______________________________________________
> Tee-dev mailing list
> Tee-dev@lists.linaro.org
>
http://lists.linaro.org/mailman/listinfo/tee-dev
>
