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.
--
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,
I believe the optee mailing is better placed to provide answers.
Regards,
Olivier.
________________________________
From: Dennis Kong via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 07 August 2025 23:44
To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
Subject: [TF-A] optee_ftpm + ms-tpm-20-ref support for RSA key sizes 3072 or 4096 causes a panic
Dear community:
I apologize in advance if this is the incorrect place to solicit for input on an issue I am having when enabling support of RSA key sizes > 2048. The environment is described below:
TI AM642-EVM board
Debian Bookworm running kernel 6.6.100, tpm_ftpm_tee.ko kernel module
Uboot booting from sdcard UEFI partition and rootfs partition
optee_os version 4.5.0 , 4.6.0, 4.7.0 (no difference in behaviour)
optee_client version 4.5.0, 4.6.0, 4.7.0 (no difference in behaviour)
optee_ftpm version 4.5.0 or 4.6.0, 4.7.0 (no difference in behaviour)
ms-tpm-20-ref commit id 98b60a44aba79b15fcce1c0d1e46cf5918400f6a and e9fc7b89d865536c46deb63f9c7d0121a3ded49c
Due to issues with RPMB, we decided to use REE_FS instead. Everything works correctly when I create RSA 2048 keys using tpm2-openssl and related tools:
sudo tpm2_createprimary -C o -G rsa2048 -g sha256 -c primary.ctx, When I try rsa3072 or 4096, I get errors from the command line response saying invalid input parameters. I changed the ms-tpm-20-ref include file TpmProfile.h to set RSA_3072 and RSA_4096 macros both to (ALG_RSA && YES). After rebuilding and running, I now get an optee panic for ANY RSA key request INCLUDING rsa2048. I read suggestions to increase the MAX_COMMAND_SIZE/MAX_RESPONSE_SIZE on both the kernel driver tpm_ftpm_tee.ko and also optee_os/optee_ftpm, as well to increase relevant TA_STACK_SIZE and TA_HEAP_SIZE and TA_DATA_SIZE, but nothing seems to change the panic output:
sudo tpm2_createprimary -C o -G rsa2048 -g sha256 -c primary.ctx============================================================
E/TC:? 0
E/TC:? 0 TA panicked with code 0xffff0007
E/LD: Status of TA bc50d971-d4c9-42c4-82cb-343fb7f37896
E/LD: arch: aarch64
E/LD: region 0: va 0x40005000 pa 0x9e8b0000 size 0x002000 flags rw-s (ldelf)
E/LD: region 1: va 0x40007000 pa 0x9e8b2000 size 0x008000 flags r-xs (ldelf)
E/LD: region 2: va 0x4000f000 pa 0x9e8ba000 size 0x001000 flags rw-s (ldelf)
E/LD: region 3: va 0x40010000 pa 0x9e8bb000 size 0x004000 flags rw-s (ldelf)
E/LD: region 4: va 0x40014000 pa 0x9e8bf000 size 0x001000 flags r--s
E/LD: region 5: va 0x40015000 pa 0x9e934000 size 0x011000 flags rw-s (stack)
E/LD: region 6: va 0x40026000 pa 0x8ebf0000 size 0x002000 flags rw-- (param)
E/LD: region 7: va 0x4006e000 pa 0x9e8c0000 size 0x058000 flags r-xs [0]
E/LD: region 8: va 0x400c6000 pa 0x9e918000 size 0x01c000 flags rw-s [0]
E/LD: [0] bc50d971-d4c9-42c4-82cb-343fb7f37896 @ 0x4006e000
E/LD: Call stack:
E/LD: 0x4006f394
E/LD: 0x40095edc
E/LD: 0x4007b5a8
E/LD: 0x400985fc
E/LD: 0x40098a70
E/LD: 0x4006fae0
E/LD: 0x400a5508
E/LD: 0x40098b9c
D/TC:? 0 user_ta_enter:195 tee_user_ta_enter: TA panicked with code 0xffff0007
D/TC:? 0 release_ta_ctx:670 Releasing panicked TA ctx
D/TC:? 0 tee_ta_invoke_command:798 Error: ffff3024 of 3
[ 218.944680] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024
[ 218.952379] tpm tpm0: tpm_try_transmit: send(): error -53212
D/TC:? 0 tee_ta_invoke_command:798 Error: ffff3024 of 3
[ 218.963359] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024
[ 218.974241] tpm tpm0: tpm_try_transmit: send(): error -53212
D/TC:? 0 tee_ta_invoke_command:798 Error: ffff3024 of 3
[ 218.985675] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024
[ 218.993366] tpm tpm0: tpm_try_transmit: send(): error -53212
[ 218.999044] tpm tpm0: tpm2_commit_space: error -14
ERROR:tcti:src/tss2-tcti/tcti-device.c:198:tcti_device_receive()D/TC:? 0 tee_ta_invoke_command:798 Error: ffff3024 of 3
Failed to get response size fd 3, got errno 14: Bad address
E[ 219.015351] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024
RROR:esys:src/tss2-esys/api/Esys_CreatePrimary.c:404:Esys_Create[ 219.028348] tpm tpm0: tpm_try_transmit: send(): error -53212
Primary_Finish() Received a non-TPM Error
ERROR:esys:src/tss2-esys/api/Esys_CreatePrimary.c:135:Esys_CreatePrimary() Esys Finish ErrorCode (0x000a000a)
ERROR: Esys_CreatePrimary(0xA000A) - tcti:IO failure
ERROR:esys:src/tss2-esys/esys_iutil.c:1145:iesys_check_sequence_async() Esys called in bad sequence.
ERROR:esys:src/tss2-esys/api/Esys_FlushContext.c:66:Esys_FlushContext() Error in async function ErrorCode (0x00070007)
=============================================================================
The last suggestion I saw was to change my dtb file to include a reserved memory region for optee shared memory and not use the default dynamic shared memory. The issue I have is kernel 6.6.100's tpm_ftpm_tee ignores the "memory-region" dts statement that references the optee_shm reserved memory at at 0xa4000000 in my case. Below is my snippet of the dts file. I heard there are patches in the kernel ftpm driver to support the reserved shared memory, but before I try the patches, can anyone opine whether this could cause the panic that I am seeing? Thanks in advance for anyone who can share any information
optee_shm: optee-shm@a4000000 {
compatible = "shared-dma-pool";
reg = <0x0 0xa4000000 0x0 0x01000000>;
no-map;
reusable;
};
....
firmware {
optee {
compatible = "linaro,optee-tz";
method = "smc";
memory-region = <&optee_shm>;
};
}
Dennis Kong, P.Eng.
Staff Engineer
Perle Systems Limited
60 Renfrew Drive,
Markham, ON L3R 0E1
(905) 475-6070 ext. 2126
Hi,
I just wanted to know, has anyone ported OPTEE on Raspberry Pi 5 ?
Is there an environment where one can run OPTEE with a Trusted App
on a Pi 5 Hardware ?
Please let me know.
Regards,
Yogesh Deshpande
Principal Engineer,
ATG Arm, Cambridge