On 09.04.21 14:56, Jan Kiszka wrote:
Hi all,
I'm currently debugging sporadic lockups in TF-A when calling the system reset hook of OP-TEE: opteed_system_reset() gets stuck on opteed_synchronous_sp_entry(), and the thread_system_reset_handler of OP-TEE is not invoked (I left a debug output on the OP-TEE side). Platform is k3, target hardware our IOT2050 device. I was using today's master of TF-A and OP-TEE, but also older versions of both.
What could cause this? I would assume that TF-A and OP-TEE are protected against overwriting of the non-secure world and we would see exceptions in case some reservation is not properly set, possibly misleading Linux.
Turned out that we had a bug in our device tree: "reserved_memory", rather than "reserved-memory". That caused Linux to ignore the RAM reservation, eventually accessing the memory that OP-TEE is using.
But that still does not explain why the secured memory is left behind unsecured. Who is responsible for that, TF-A or the TEE itself?
Jan