On 6/16/17 7:31 PM, Thomas M Zeng wrote:
Hi Jens and Stuart:
#define OPTEE_SMC_SEC_CAP_DYNAMIC_SHM vs. UNRESITERED_SHM (1 << 1)
The topic of managing RichOS-and-TEE shared memory for *use case* scalability is of interest to Qualcomm as well. We might want to reserve "DYNAMIC_SHM" to mean that additional contiguous physical memory regions can be runtime registered / deregistered with Secure World, and the CA's can suballocate from these, just like they suballocate from the initial 1MB of carveout.
Meanwhile, the SMC_SEC_CAP_UNREGISTERED_SHM flag might be a better name to communicate the semantics that the Secure World, as a matter of policy, allows any NS memory to be mapped to TAs without restrictions.
That is to say, the semantics of SMC_CAP_DYNAMIC_REGISTER_SHM might better off set aside for future, when, post boot, some contiguous NS=1 regions can be added to the SHM pool, in order to lift the limitation of the initial 1MB SHM pool.
Granted it requires the addition of new SMC commands. That is why I chose the word, “future”.
Thoughts?
What I object to is using the word "register" in the same capabilities list in 2 completely different ways.
The capability OPTEE_SMC_SEC_CAP_CMD_REGISTER_SHM means-- op-tee supports the register/unregister client API commands. It allows a client app to "register" a buffer with op-tee.
OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM means as you suggest-- that op-tee allows any NS memory to be mapped.
So in order to support "REGISTER_SHM" op-tee must support "UNREGISTERED_SHM". That is seriously confusing.
We could try to be very explicit. Instead of "dynamic":
OPTEE_SMC_SEC_CAP_CAN_MAP_ALL_NS_MEM
I would be happy with that.
Stuart