Hello
I was wondering whether the current op-tee os support this that secure monitor would trigger the op-tee to handle the native interrupter without forwarding it to the REE?
If the answer is yes, could it lead to a dead lock when the linux kernel is holding a spinlock(usually irq is disabled in that CPU core) ?
I didn't find much about how should we handle the secure interrupter from document, the general way seems to either forward it to REE or just don't use the secure interrupter at all.
Let the REE handle the interrupter may not be a good idea, since the device could we should ack the interrupter in it, is protected by the trustzone, we need to switch CPU to secure mode to handle this tiny task.
I wish I could know more solution about the interrupter here.
Sincerely
Randy
Hi Randy,
On Mon, 27 Nov 2023 at 13:03, Randy Li via OP-TEE op-tee@lists.trustedfirmware.org wrote:
Hello
I was wondering whether the current op-tee os support this that secure monitor would trigger the op-tee to handle the native interrupter without forwarding it to the REE?
I would suggest you to go through this doc [1] to see if it answers all your questions. If not then let us know, we will help to clarify further.
[1] https://optee.readthedocs.io/en/latest/architecture/core.html#interrupt-hand...
-Sumit
If the answer is yes, could it lead to a dead lock when the linux kernel is holding a spinlock(usually irq is disabled in that CPU core) ?
I didn't find much about how should we handle the secure interrupter from document, the general way seems to either forward it to REE or just don't use the secure interrupter at all.
Let the REE handle the interrupter may not be a good idea, since the device could we should ack the interrupter in it, is protected by the trustzone, we need to switch CPU to secure mode to handle this tiny task.
I wish I could know more solution about the interrupter here.
Sincerely
Randy
On 2023/12/4 21:54, Sumit Garg wrote:
Hi Randy,
On Mon, 27 Nov 2023 at 13:03, Randy Li via OP-TEE op-tee@lists.trustedfirmware.org wrote:
Hello
I was wondering whether the current op-tee os support this that secure monitor would trigger the op-tee to handle the native interrupter without forwarding it to the REE?
I would suggest you to go through this doc [1] to see if it answers all your questions. If not then let us know, we will help to clarify further.
[1] https://optee.readthedocs.io/en/latest/architecture/core.html#interrupt-hand...
-Sumit
"When a secure interrupt is signaled by the Arm GIC, it shall reach the OP-TEE OS interrupt exception vector. If the secure world is executing, OP-TEE OS will handle interrupt straight from its exception vector."
And Section "Deliver secure interrupt to secure world when SCR_NS is set"
I think those are the answer to my initial question.
But I didn't see such practice. In the recent changes to Linux kernel, likes OP-TEE notifications, I think the most of platforms would like not let the Secure OS handle the devices' interrupters? I didn't know such a driver in Linux kernel either.
When a CPU core, which is holding a spinlock, have been restored to Secure context by monitor, would it halt the other cores which are waiting for the release of that spinlock?
Besides, when we use a spinlock in the kernel, in the most of time, we except all IRQs are masked(spin_lock_irqsave), could this masked the secure interrupter?
Also, I didn't see there is a guideline about how OP-TEE os should handle native interrupt in this case. If it took too much time, it may lead an innocent process be regarded as hardlockup (or softlockup if it turns to REE after all) in the linux kernel.
If the answer is yes, could it lead to a dead lock when the linux kernel is holding a spinlock(usually irq is disabled in that CPU core) ?
I didn't find much about how should we handle the secure interrupter from document, the general way seems to either forward it to REE or just don't use the secure interrupter at all.
Let the REE handle the interrupter may not be a good idea, since the device could we should ack the interrupter in it, is protected by the trustzone, we need to switch CPU to secure mode to handle this tiny task.
I wish I could know more solution about the interrupter here.
Sincerely
Randy
op-tee@lists.trustedfirmware.org
-
Randy Li -
Sumit Garg