On Wed, 31 Jul 2019 at 16:33, Janne Karhunen janne.karhunen@gmail.com wrote:
On Wed, Jul 31, 2019 at 1:26 PM Sumit Garg sumit.garg@linaro.org wrote:
Interesting, I wrote something similar and posted it to the lists a while back: https://github.com/jkrh/linux/commit/d77ea03afedcb5fd42234cd834da8f8a0809f6a...
Since there are no generic 'TEEs' available,
There is already a generic TEE interface driver available in kernel. Have a look here: "Documentation/tee.txt".
I guess my wording was wrong, tried to say that physical TEEs in the wild vary massively hardware wise. Generalizing these things is rough.
There are already well defined GlobalPlatform Standards to generalize the TEE interface. One of them is GlobalPlatform TEE Client API [1] which provides the basis for this TEE interface.
I implemented the same thing as a generic protocol translator. The shared memory binding for instance already assumes fair amount about the TEE and how that is physically present in the system. Besides, the help from usage of shm is pretty limited due to the size of the keydata.
If you look at patch #1 and #2, they add support to register kernel memory buffer (keydata buffer in this case) with TEE to operate on. So there isn't any limitation due to the size of the keydata.
Ah, didn't mean that. Meant that the keydata is typically pretty small in size, so there is limited benefit from passing that in via shm if that complicates anything.
Ah, ok. Do you think of any better approach rather than to use SHM?
[1] https://globalplatform.org/specs-library/tee-client-api-specification/
-Sumit
-- Janne