Hi,
We would like to protect trusted application heap memory against cryogenic attacks. We think a good method to achieve this is by employing the Bus Encryption Engine hardware in our i.MX6UL. For testing, I currently configure the BEE in U-Boot, to encrypt the Op-Tee TA_RAM area (0x8e100000-8f9fffff), and make it available unencryptedly at 0x10000000-0x118fffff. TA_RAM_START is set to 0x10000000 and this seems to work, but I have a few questions: 1. Does area TA_RAM_START:TA_RAM_SIZE hold all TA code, stack and heap? 2. Access privileges to 0x10000000-0x118fffff have been set to *Non-Secure User none, Non-Secure Spvr none, Secure User RD + WR, Secure Spvr RD + WR*, but much to my surprise, *Non-Secure User none, Non-Secure Spvr none, Secure User none, Secure Spvr RD + WR* worked equally well.
I can provide a memory map if useful, but I'd rather not post that at forehand.
If this works well, achieves our goal and the performance penalty is acceptable, we will roll this into an Op-Tee driver.
With kind regards,
Robert.
Hi Robert,
On Wed, Aug 13, 2025 at 4:48 PM Robert Delien via OP-TEE op-tee@lists.trustedfirmware.org wrote:
Hi,
We would like to protect trusted application heap memory against cryogenic attacks. We think a good method to achieve this is by employing the Bus Encryption Engine hardware in our i.MX6UL. For testing, I currently configure the BEE in U-Boot, to encrypt the Op-Tee TA_RAM area (0x8e100000-8f9fffff), and make it available unencryptedly at 0x10000000-0x118fffff. TA_RAM_START is set to 0x10000000 and this seems to work, but I have a few questions:
- Does area TA_RAM_START:TA_RAM_SIZE hold all TA code, stack and heap?
Yes. However, on the latest releases, we've started to merge the physical memory areas reserved for OP-TEE core and TAs. So there's a risk that things may become a bit more complicated in upstream.
- Access privileges to 0x10000000-0x118fffff have been set to *Non-Secure
User none, Non-Secure Spvr none, Secure User RD + WR, Secure Spvr RD + WR*, but much to my surprise, *Non-Secure User none, Non-Secure Spvr none, Secure User none, Secure Spvr RD + WR* worked equally well.
Where do you set these access privileges?
I can provide a memory map if useful, but I'd rather not post that at forehand.
If this works well, achieves our goal and the performance penalty is acceptable, we will roll this into an Op-Tee driver.
Sounds interesting.
Cheers, Jens
With kind regards,
Robert.-- DISCLAIMER De informatie, verzonden in of met dit e-mailbericht, is vertrouwelijk en uitsluitend voor de geadresseerde(n) bestemd. Het gebruik van de informatie in dit bericht, de openbaarmaking, vermenigvuldiging, verspreiding en|of verstrekking daarvan aan derden is niet toegestaan. Gebruik van deze informatie door anderen dan geadresseerde(n) is strikt verboden. Aan deze informatie kunnen geen rechten worden ontleend. U wordt verzocht bij onjuiste adressering de afzender direct te informeren door het bericht te retourneren en het bericht uit uw computersysteem te verwijderen.
Hi Jens,
Thank you for your prompt response.
Yes. However, on the latest releases, we've started to merge the physical memory areas reserved for OP-TEE core and TAs. So there's a risk that things may become a bit more complicated in upstream.
Thanks for the heads-up; We will cross that bridge when we get there. Updating Op-Tee to a more recent version is on my list too, but is further down due to our large number of proprietary drivers, but also to how good version 3.10 is.
In my current test setup, I have the BEE configured in U-Boot to use memory at the original TA_RAM_START (@0x8e100000) and make it available unencryptedly at 0x10000000. I have tested it in U-Boot and it seems to work properly.
In Op-Tee's generic_ram_layout.h, I basically renamed TA_RAM_START to TA_RAM_START*_BEE*, and used TA_RAM_START*_BEE* in the macro calculating TA_RAM_SIZE. TA_RAM_START itself has been hard-coded to 0x10000000. (This is just a test, I will use the Device Tree later).
Before: D/TC:0 add_phys_mem:597 TA_RAM_START type TA_RAM *0x8e100000* size 0x01900000 D/TC:0 dump_mmap_table:744 type TA_RAM va 0x89200000..0x8aafffff pa *0x8e100000*..0x8f9fffff size 0x01900000 (pgdir) D/TC:0 0 carve_out_phys_mem:297 No need to carve out *0x8e100000* size 0x1900000
After: D/TC:0 add_phys_mem:598 TA_RAM_START type TA_RAM *0x10000000* size 0x01900000 D/TC:0 dump_mmap_table:745 type TA_RAM va 0x89200000..0x8aafffff pa *0x10000000*..0x118fffff size 0x01900000 (pgdir) D/TC:0 0 carve_out_phys_mem:298 No need to carve out *0x10000000* size 0x1900000
(The order in logging between different areas differs between before and after, but I've been assuming that does not make a difference.)
At first glance it seems to work, but TAs are producing errors with anything they do. I realize TA_RAM_START was probably never intended to be used this way, but I also might be forgetting something obvious.
I have instrumented mobj_phys_alloc() with debug prints printing physical addresses, when loading TAs, but nothing gets printed for battr == CORE_MEM_TA_RAM. Do you have a suggesting where better to print TA_RAM being allocated?
Where do you set these access privileges?
The BEE peripheral has a bitfield to set access privileges for its 2 aliasing areas. I expect the underlying RAM is still covered by the TZ controller, but making sure of that is still on my list.
Sounds interesting.
I may be able to convince people here to push this driver upstream if we get it to work.
Any suggestions you may have will be highly appreciated.
With kind regards,
Robert.
On Wed, Aug 13, 2025 at 5:07 PM Jens Wiklander jens.wiklander@linaro.org wrote:
Hi Robert,
On Wed, Aug 13, 2025 at 4:48 PM Robert Delien via OP-TEE op-tee@lists.trustedfirmware.org wrote:
Hi,
We would like to protect trusted application heap memory against
cryogenic
attacks. We think a good method to achieve this is by employing the Bus Encryption Engine hardware in our i.MX6UL. For testing, I currently configure the BEE in U-Boot, to encrypt the Op-Tee TA_RAM area (0x8e100000-8f9fffff), and make it available unencryptedly at 0x10000000-0x118fffff. TA_RAM_START is set to 0x10000000 and this
seems
to work, but I have a few questions:
- Does area TA_RAM_START:TA_RAM_SIZE hold all TA code, stack and heap?
Yes. However, on the latest releases, we've started to merge the physical memory areas reserved for OP-TEE core and TAs. So there's a risk that things may become a bit more complicated in upstream.
- Access privileges to 0x10000000-0x118fffff have been set to
*Non-Secure
User none, Non-Secure Spvr none, Secure User RD + WR, Secure Spvr RD +
WR*,
but much to my surprise, *Non-Secure User none, Non-Secure Spvr none, Secure User none, Secure Spvr RD + WR* worked equally well.
Where do you set these access privileges?
I can provide a memory map if useful, but I'd rather not post that at forehand.
If this works well, achieves our goal and the performance penalty is acceptable, we will roll this into an Op-Tee driver.
Sounds interesting.
Cheers, Jens
With kind regards,
Robert.-- DISCLAIMER De informatie, verzonden in of met dit e-mailbericht, is vertrouwelijk en uitsluitend voor de geadresseerde(n) bestemd. Het
gebruik
van de informatie in dit bericht, de openbaarmaking, vermenigvuldiging, verspreiding en|of verstrekking daarvan aan derden is niet toegestaan. Gebruik van deze informatie door anderen dan geadresseerde(n) is strikt verboden. Aan deze informatie kunnen geen rechten worden ontleend. U
wordt
verzocht bij onjuiste adressering de afzender direct te informeren door
het
bericht te retourneren en het bericht uit uw computersysteem te
verwijderen.
op-tee@lists.trustedfirmware.org
-
Jens Wiklander -
Robert Delien