Jan,

On 13:18-20210410, Jan Kiszka 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?

I dont think it will, but you might have already seen [1]? I think the area reserved for xlat tables were off. esp [2]

Now that said, I dont recollect that the MMU tables in trustzone(EL3) and normal EL2/1 world synchronize among themselves. It might even have been R5 or DMA that could have generated traffic and those would'nt care for the MMU table protections in A53 anyways.

In cases like these, You should explicitly set SRAM or DDR firewalls as the case might be to allow only A53 secure access to prevent scenarios like these. In K3, you'd want to do the firewall configuration prior to starting A53 up (So, R5 SPL or which ever bootloader that might be involved).

[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/9424 [2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/9425/1