Closed etienne-lms closed 1 year ago
The fact some tee threads many not be available (be lost) complexify a bit the logic.
That's one of the things I think can be simplified, as long as the logic doesn't break down completely that problem can be ignored. I mean, there are much worse things that can happen if the secure world starts to misbehave.
I mean, there are much worse things that can happen if the secure world starts to misbehave.
In that case, it is not a misbehaviour from the TEE, it rather how normal world secure plays with OP-TEE threads. An ealier boot stage could have left a thread suspended. It is not awaited but what if it happens? TEE and REE should not panic.
I mean, there are much worse things that can happen if the secure world starts to misbehave.
In that case, it is not a misbehaviour from the TEE, it rather how normal world secure plays with OP-TEE threads. An ealier boot stage could have left a thread suspended. It is not awaited but what if it happens? TEE and REE should not panic.
Agreed, panic should be avoided. However, a boot stage handing over with threads active in the secure world is an error. So whatever we do after that is only best-effort.
See another attempt at https://github.com/linaro-swg/linux/pull/110
Closing, superseded by https://github.com/linaro-swg/linux/pull/110.
Superseeds https://github.com/linaro-swg/linux/pull/108.
During reviews on how to provision TEE threads for system service, we considered a scheme where Linux kernel monitors system and regular TEE sessions, whitout extra services on OP-TEE secure side.
This RFC pull request proposed such an implementation. It is shared here and will be posted to LKML if we it's a prefered way, vesus what was proposed in https://github.com/linaro-swg/linux/pull/108.