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.
Thank you for your help! Konstantin
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
-----Original Message----- From: Jens Wiklander jens.wiklander@linaro.org Sent: Wednesday, May 22, 2019 16:39 To: Kostya Porotchkin kostap@marvell.com Cc: tee-dev@lists.linaro.org Subject: [EXT] Re: [Tee-dev] SRAM support for crypto keys storage without CFG_WITH_PAGER
External Email
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
[KP] Currently I am thinking about protection of a set of keys loaded and decrypted by the OP-TEE OS kernel at startup. I need to do this only once, since the root decryption key has "read once" behavior and will not be available at later stages (protected by the HW till the next reboot). My plans are also add security accelerator HW support in the future. This type of HW has separate pointers to the data payload and secure context locations and not expected to leak the key information into DRAM. Looking through "init_runtime" function that in non-pager mode all memory allocations are coming from common heap in TZ DDR. Is it true?
Thanks Konstantin
-
Jens Wiklander -
Kostya Porotchkin