All,
I am new to secure world and op-tee and one thing I’m trying to understand is what the /dev/teeN and /dev/teeprivN device files in Linux conceptually represent.
I’ve run the QEMU-based example, and I can see that /dev/tee0 and /dev/teepriv0 exist and the app uses tee0 and the supplicant uses teepriv0.
What if I want to run multiple app/TA pairs at the same—do all open and share share the same /dev/tee0 file?
If so, what is the scenario where you would ever have a /dev/tee1 and so on. From what I can see, the Linux driver is creating just one pair of device files.
Do app/TAs always function in pairs? Is there ever a case where a “helloworld” TA was loaded once, and then multiple normal world apps would use it? …or, is it that an app that needs a secure TA service always loads the corresponding TA itself, even if it meant duplicating the TA.
Thanks, Stuart
Hi Stuart,
On Thu, Mar 23, 2017 at 11:01 PM, Stuart Yoder Stuart.Yoder@arm.com wrote:
All,
I am new to secure world and op-tee and one thing I’m trying to understand is what the /dev/teeN and /dev/teeprivN device files in Linux conceptually represent.
I’ve run the QEMU-based example, and I can see that /dev/tee0 and /dev/teepriv0 exist and the app uses tee0 and the supplicant uses teepriv0.
What if I want to run multiple app/TA pairs at the same—do all open and share share the same /dev/tee0 file?
Yes
If so, what is the scenario where you would ever have a /dev/tee1 and so on. From what I can see, the Linux driver is creating just one pair of device files.
If there's multiple TEEs for instance one TrustZone based and one on a separate processor.
Do app/TAs always function in pairs? Is there ever a case where a “helloworld” TA was loaded once, and then multiple normal world apps would use it? …or, is it that an app that needs a secure TA service always loads the corresponding TA itself, even if it meant duplicating the TA.
Normally it's like you describe it, but it depends on how the TA is configured. There's one configuration where the TA only is represented in one instance with multiple sessions. Then all clients communicates with the same TA but in different sessions (everything serialized, no concurrent execution in the TA).
The OP-TEE design is based "TEE System Architecture", "TEE Client API Specification" and "TEE Internal Core API Specification" at https://www.globalplatform.org/specificationsdevice.asp
Reading those specs will help when trying to understand how OP-TEE works.
Regards, Jens