[RFC] Provision TEE threads for system invocation (take2)

[etienne-lms]

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.

[jenswi-linaro]

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.

[etienne-lms]

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.

[jenswi-linaro]

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.

[jenswi-linaro]

See another attempt at https://github.com/linaro-swg/linux/pull/110

[etienne-lms]

Closing, superseded by https://github.com/linaro-swg/linux/pull/110.