Hi Konstantin,
On Wed, May 22, 2019 at 1:57 PM Kostya Porotchkin kostap@marvell.com wrote:
Hello,
My platform (armada7k8k) does not have a native ("true") SRAM, but a part of CPU last level cache (LLC) could be switched into SRAM mode. The resulting SRAM is quite small and is not immediately available at OP-TEE OS entry point, thus could not contain the OP-TEE OS code itself. However I would like to keep cryptographic keys there (the SRAM is located on the CPU die) instead of using external (unencrypted) TZ DRAM. As far as I can see from the OS core code, the TZSRAM_* definitions are only taken into account when the pager is enabled. Which part of the OP-TEE OS core should be reviewed for the required changes? How do I ensure that the memory for crypto keys is always allocated form the secure SRAM pull? I prefer to use the existing OS infrastructure instead of adding proprietary memory and key management code.
OP-TEE doesn't have the infrastructure to do exactly what you want. Currently keys can be copied into the stack and the heap as functions are working with them. Perhaps you could narrow down which keys you need to protect. Do you also need to protect keys generated by TAs via the GP API?
Cheers, Jens