Thank you, Jens, for the detail. Yes, the idea is to re-use as much of the source as possible, and the bar is xtest compliance. Good insights, thank you!
Best, Jork
-----Original Message----- From: Jens Wiklander jens.wiklander@linaro.org Sent: Tuesday, November 12, 2024 00:49 To: Jork Loeser (he/him) Jork.Loeser@microsoft.com Cc: op-tee@lists.trustedfirmware.org Subject: [EXTERNAL] Re: Linux user-level implementation of OP-TEE
[You don't often get email from jens.wiklander@linaro.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
Hi Jork,
On Tue, Nov 12, 2024 at 8:54 AM Jork Loeser (he/him) via OP-TEE <op- tee@lists.trustedfirmware.org> wrote:
Hello,
I am Jork Loeser from Microsoft, and we are looking into providing the OP-
TEE internal core API from Linux user-level, as well as hosting a derivative of OP-TEE OS in Linux user-level. Can you say is something like this has been attempted in the past, and perhaps provide pointers?
I'm not aware of any attempts at this.
How interesting would it be for OP-TEE to have such an implementation -
e.g., for early/rapid-development purposes?
That depends on the accuracy of the implementation and who will maintain it. The implementation should preferably not lag behind the normal OP-TEE development or that might be a source of confusion.
I'm probably not in the target group, but I think an environment based on QEMU might still be preferable due to its accuracy and closeness to the real deal. It's also quite quick to develop TAs using QEMU. You can usually do incremental compiles and re-launch in only a few seconds. It can be a bit challenging to attach a debugger to a TA, and even worse when more TAs are executed in parallel. This is an area with room for improvement. OP-TEE OS and TA awareness in GDB would help with lowering the bar.
Cheers, Jens