Hi Thomas,
On Tue, Dec 6, 2016 at 6:34 PM, thomas m zeng tzeng@codeaurora.org wrote:
Hi Jens,
On the topic of integrating TEE with Hyp in a Multi-VM environment like Volodymyr wants to do, we would not feel comfortable to get rid of the "shm pool" concept, specifically the shm allocation from the carveout.
I agree that we should keep the pool, for some configurations.
We would disagree with a protection model where any NS buffer, from any client operating system or from EL2, can be shared with the Secure World. The reason is we desire to sandbox NS EL1 and NS EL2 from Secure world, since in the past, people have used the loop holes in TAs to root Linux kernel. Google "bitsplease" if you want any recent example.
Granted in ARM architecture, SEL1 can always gain access to the entire NS memory space, but SEL0 does not have that power, nor does some of the non-ARM-Trustzone TEEs.
Last I checked, Gen TEE Driver has the mandate to work with any TEE. We agree with that goal :-)
:-)
Having said that, we also agree with Volodymyr, always max out the carveout is not terribly space-efficient.
When we rework MM in OP-TEE, would the SHM protocol, currently implemented in drivers/tee as a generic protocol (namely not specific to OP-TEE), be subject to some twicks?
Sorry, I don't understand, which protocol?
Thanks, Jens