On Thu, 1 Aug 2019 at 13:00, Janne Karhunen janne.karhunen@gmail.com wrote:
On Thu, Aug 1, 2019 at 9:50 AM Rouven Czerwinski r.czerwinski@pengutronix.de wrote:
I'm aware of it - I have implemented a large part of the GP TEE APIs earlier (primarily the crypto functions). Does the TEE you work with actually support GP properly? Can I take a look at the code?
AFAIK Sumit is working with the OP-TEE implementation, which can be found on github: https://github.com/op-tee/optee_os
Thanks, I will take a look.
For documentation, refer to: https://optee.readthedocs.io/
The fundamental problem with these things is that there are infinite amount of ways how TEEs and ROTs can be done in terms of the hardware and software. I really doubt there are 2 implementations in existence that are even remotely compatible in real life.
I agree with you regarding implementation specific nature of TEE but having a standardized client interface does solves the problem.
As such, all things TEE/ROT would logically really belong in the userland and thanks to the bpfilter folks now the umh logic really makes that possible ... I think. The key implementation I did was just an RFC on the concept, what if we start to move the stuff that really belongs in the userspace to this pseudo-userland. It's not kernel, but it's not commonly accessible userland either. The shared memory would also work without any modifications between the umh based TEE/ROT driver and the userland if needed.
Anyway, just my .02c. I guess having any new support in the kernel for new trust sources is good and improvement from the current state. I can certainly make my stuff work with your setup as well, what ever people think is the best.
Yes your implementation can very well fit under trusted keys abstraction framework without creating a new keytype: "ext-trusted".
-Sumit
-- Janne