Hi Jan,
On Sat, Apr 10, 2021 at 1:18 PM Jan Kiszka via TF-A tf-a@lists.trustedfirmware.org wrote:
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?
This might be memory reserved for the static shared memory pool used when communicating between Linux normal world and OP-TEE in secure world. If that's the case it's normal that the memory is accessible from Linux, however if Linux uses it for other purposes too there will be memory corruptions.
Cheers, Jens
On 15.04.21 09:36, Jens Wiklander wrote:
Hi Jan,
On Sat, Apr 10, 2021 at 1:18 PM Jan Kiszka via TF-A tf-a@lists.trustedfirmware.org wrote:
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?
This might be memory reserved for the static shared memory pool used when communicating between Linux normal world and OP-TEE in secure world. If that's the case it's normal that the memory is accessible from Linux, however if Linux uses it for other purposes too there will be memory corruptions.
To my understanding, OP-TEE is completely in RAM on the k3. And that RAM requires protection via a platform specific memory firewall. We very likely have an issue there, still analyzing this, also with the help of TI. Fortunately, security features were not yet exploited on our hw in practice so far (to our best knowledge).
Thanks, Jan
tf-a@lists.trustedfirmware.org
-
Jan Kiszka -
Jens Wiklander