About optee pager

[GrandChariot]

Hi, I'm using stm32 board and rpi3 board. I noticed that only stm32 board supports secure SRAM and pager as I looked through OPTEE codes. But I also noticed that stm32 board is much slower than rpi3 board because of paging. What are advantages of paging? Is it much safer than DRAM-only? Why only stm32 board supports secure SRAM and paging?

Thank you.

[etienne-lms]

On stm32mp1, external DRAM is not scrambled/encrypted/... hence is not secure enough to run OP-TEE in clear. Stm32mp1 has a secure internal RAM where OP-TEE can be executed safely. It is 256kB large, not much. OP-TEE Pager allows secure world (core & TAs) to execute in such a small memory at the cost of swapping secure pages to/from non-secure RAM (with authenticated encryption).

Platforms supporting secure and large external RAM(s) have no interest in enabling pager support.

(edited)

[GrandChariot]

@etienne-lms

Thank you very much for your quick reply. It was a great help.

According to your answer, I would appreciate it if you could reply to a few more questions.

According to the answer, the DRAM of stm32 is not safe, so is the DRAM of other boards safe? In particular, rpi3 is not safe according to OPTEE documents, so does rpi3 have unsafe DRAMs like stm32? If so, can I use it safely like any other board if I apply the page to rpi3? How do I guess which board's DRAM is safe or not?

Thank you again for your kind reply.

[etienne-lms]

In particular, rpi3 is not safe according to OPTEE documents, so does rpi3 have unsafe DRAMs like stm32?

I don't think rpi3 embeds an internal secure RAM suitable to run OP-TEE. I'm not sure rpi3 can be configured to enable some memory firewalling and other TZ secure hardening means.

How do I guess which board's DRAM is safe or not?

You should refer to the devices documentation to see which embed secure memory. Maybe ask the boards' maintainers.

[janoslim]

Hello, @etienne-lms,

I just encountered this issue and I wonder why "pager" is not available on arm64(I tried to build optee with CFG_WITH_PAGER=y and get message about arm64 does not support pager) as using pager give more secure state than without pager as mentioned here(https://www.usenix.org/conference/raid2019/presentation/zhao). So I wonder if this is because technically impossible or if it hasn't been implemented yet as there seems to be no support of pager to arm64 boards.

Thank you!

[etienne-lms]

Pager works fine on 64bit machines. You can try OP-TEE qemu_v8.xml with make run CFG_WITH_PAGER=y.

For rpi3, if there is an internal RAM you can secure and execute OP-TEE in, then build plat-rpi3 with CFG_WITH_PAGER=y CFG_TZSRAM_START=<sram-base-address> CFG_TZSRAM_START=<sram-bye-size> and remove from _plat-rpi3/platformconfig.h:

 /* Make stacks aligned to data cache line length */
 #define STACK_ALIGNMENT        64

-#ifdef ARM64
-#ifdef CFG_WITH_PAGER
-#error "Pager not supported for ARM64"
-#endif
-#endif /* ARM64 */
-
 /* 16550 UART */
 #define CONSOLE_UART_BASE  0x3f215040 /* UART0 */

If you just want to try rpi3 with pager enabled, emulating the internal RAM with a piece of DRAM, then build plat-rpi3 with CFG_WITH_PAGER=y (and apply the above patch of course). rpi3 relies on _generic_ramlayout.h so enabling CFG_WITH_PAGER=y without CFG_TZSRAM_START makes CFG_CORE_TZSRAM_EMUL_SIZE (defaults to 448kB, see core/arch/arm/arm.mk) to define the size of an emulated internal RAM in secure DRAM and pager to operate in emulated SRAM. This is how we emulate pager RAM in both _qemuvirt and _qemuv8, when CFG_WITH_PAGER=y.

Thanks for the article reference. Interesting.

[janoslim]

@etienne-lms Thank you! It seems works fine!

[symdeb]

ST decided to move the OPTEE to DDR for the STMP32MP15 (384KB SRAM) by default on the latest ECO system with an option for change to back for SYSTEM, On the STM32MP13 the SRAM is even smaller (180KB) but it uses a new protection mechanism for using to DDR. If this SRAM is such a performance limitation why did the manufacturers not make it larger and what would be a minimum size ? Why would ST who is pushing security (TEE) a lot and recommends secure OPTEE in SYSRAM but not enable it by default ? Is OP-TEE really that useful/helpful ? For example, what is the advantange of OP-TEE instead of just implementing an external cheap secure element IC as most use cases seem to be are for keys and certificates. It looks like things TEE can provide that SE (currently) can't is loading custom applications and saves board space.