- TF-M - lists.trustedfirmware.org

How does TF-M deal with the faults originated from NSPE

by Sandeep Tripathy

Hi tf-m experts, I have a fundamental query on v8m trustZone and containability of secure fault and other escalated HardFaults to SPE. With BFHFNMINA set to '0' IIUC that a malicious actor in NSPE can willingly cause fault in SPE ? Is there a way to contain the fault in NS world? Thanks Sandeep

1 year, 9 months

4
5
1 0

Please help check the failure of PSA_ALG_HKDF_EXPAND operation test

by Edward Yang

Hi experts, Recently we're testing the HKDF-EXPAND interface with TF-M v1.7.0 on stm32l562e_dk platform. But the HKDF-EXPAND output didn't match the expected OKM. The test vector is as below: ALG : PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256), "info" : decode_hex("f0f1f2f3f4f5f6f7f8f9"), "L" : 42, "PRK" : "077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5" "OKM" : "3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865" The corresponding code is as follow： int8_t okm[42]={0}; uint8_t info[] = {0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9}; uint8_t ikm[]= { 0x7,0x77,0x9,0x36,0x2c,0x2e,0x32,0xdf, 0xd,0xdc,0x3f,0xd,0xc4,0x7b,0xba,0x63, 0x90,0xb6,0xc7,0x3b,0xb5,0xf,0x9c,0x31, 0x22,0xec,0x84,0x4a,0xd7,0xc2,0xb3,0xe5 }; status = psa_key_derivation_setup(&operation, PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_SECRET, ikm, sizeof(ikm)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_INFO, info, sizeof(info)); status = psa_key_derivation_output_bytes( &operation, okm, sizeof(okm) ); The actual output okm is : 5a 1c ea 2d 24 ee 79 c5 bf ce 27 7b ... be b 3b 2e 19 18 77 ae, which didn't match the OKM of above test vector. Have we misused the HKDF-EXPAND operation? Best Regards, Poppy Wu 吴偏偏 http://www.mxic.com.cn

1 year, 9 months

2
2
0 0

Please help check the failure of PSA_ALG_HKDF_EXPAND operation test

by Wenhua You

Hi experts, Recently we're testing the HKDF-EXPAND interface with TF-M v1.7.0 on stm32l562e_dk platform. But the HKDF-EXPAND output didn't match the expected OKM. The test vector is as below: ALG : PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256), "info" : decode_hex("f0f1f2f3f4f5f6f7f8f9"), "L" : 42, "PRK" : "077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5" "OKM" : "3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865" The corresponding code is as follow： int8_t okm[42]={0}; uint8_t info[] = {0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9}; uint8_t ikm[]= { 0x7,0x77,0x9,0x36,0x2c,0x2e,0x32,0xdf, 0xd,0xdc,0x3f,0xd,0xc4,0x7b,0xba,0x63, 0x90,0xb6,0xc7,0x3b,0xb5,0xf,0x9c,0x31, 0x22,0xec,0x84,0x4a,0xd7,0xc2,0xb3,0xe5 }; status = psa_key_derivation_setup(&operation, PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_SECRET, ikm, sizeof(ikm)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_INFO, info, sizeof(info)); status = psa_key_derivation_output_bytes( &operation, okm, sizeof(okm) ); The actual output okm is : 5a 1c ea 2d 24 ee 79 c5 bf ce 27 7b ... be b 3b 2e 19 18 77 ae, which didn't match the OKM of above test vector. If we've misused the HKDF-EXPAND operation? Best Regards, 尤文华 Wenhua You 旺宏微电子（苏州）有限公司 Macronix Microelectronics(Suzhou) Co., Ltd. 地址：中国苏州工业园区苏虹西路55号 No.55，Su Hong Xi Road，Suzhou Industrail Park，Suzhou 215021 P.R.China TEL: 86-512-62580888 EXT: 3115 FAX: 86-512-62585399 ZIP: 215021 E-mail: wenhuayou(a)mxic.com.cn Http: //www.mxic.com.cn

1 year, 9 months

1
0
0 0

Sealing key - RSS

by Peter Sawicki

As far as ARM CCA is concerned, currently RSS supports only measured boot and delegated attestation (fetching DAK and CCA platform attestation token) interfaces. The Arm CCA Security Model 1.0 mentions that if a Realm wants to implement a persistent secure storage, the platform should deliver binding keys for local protection of persistent Realm assets. Is there any ARM CCA specification that explains how this key should be derived? Are there any plans to implement such functionality in RSS? Kind regards, Peter

1 year, 9 months

3
4
0 0

TF-M scheduling

by Chris.Brand＠infineon.com

Hi, I've read https://tf-m-user-guide.trustedfirmware.org/integration_guide/non-secure_cl… and https://tf-m-user-guide.trustedfirmware.org/design_docs/software/tfm_cooper… but I'm not sure that I understand the whole system. For example, in this scenario: 1. NSPE is running a low-priority thread which has called into the PSA API. S partition is running to do the work. 2. NS interrupt occurs. 3. NS RTOS determines that a higher-priority thread should now run. At step 2, the S context gets stored on the S stack. I guess at step 3 the NS RTOS ISR would manipulate the stack so that it "returns" to the higher-priority NS thread rather than to the secure partition? And then sometime later when it schedules in the low-priority thread, it will return to the interrupted S partition. So the higher-priority thread can also make a PSA API call (provided the NS RTOS is notifying TF-M of the scheduling decisions it makes)? Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> www.infineon.com<www.cypress.com> www.cypress.com<http://www.cypress.com/> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies> Part of your life. Part of tomorrow. NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.

1 year, 9 months

1
0
0 0

Scheduler problem

by Bohdan.Hunko＠infineon.com

Hi everyone, Why investigation some interrupts related stuff I have noticed a problem/bug in the scheduler. PendSV_Handler has following code: " movs r0, #"M2S(EXC_RETURN_SECURE_STACK)" \n" " mov r1, lr \n" " tst r0, r1 \n" /* NS interrupted */ " beq v8b_pendsv_exit \n" /* No schedule */ Which means that if NSPE was interrupted then no scheduling will be done. This created a problem in following scenario: 1. NSPE is executing 2. Secure interrupts arrives. 3. NSPE is interrupted, secure interrupt is handled. 4. Secure interrupts triggers scheduling of some partition. 5. Secure interrupt returns 6. Scheduling is triggered 7. PendSV returns (because /* NS interrupted */ /* No schedule */ ) and does not perform scheduling even thought pending partition is present. This means that pending partition will only be scheduled when next PSA call will be done be NSPE. Even if there would be subsequent Secure interrupts that preempt NSPE, partition will not be scheduled because PendSV will always return without scheduling because NSPE was interrupted. I was not able to find any information about this in TFM docs so I assume this is a bug. Please let me know if I am wrong. And if this is real problem then is there a plan to fix this? Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

1 year, 9 months

2
1
0 0

Support mbedTLS 3.3.0

by S Krishnan, Archanaa

Hi, TF-M v1.7 utilizes mbedTLS v3.2.1. Are there plans to update to mbedTLS v3.3.0? Regards, Archanaa

1 year, 9 months

2
1
0 0

Partitions without manifest files are not linked correctly in L3

by Bohdan.Hunko＠infineon.com

In isolation level 3 partitions code/data in linker script are gathered together and aligned using information from manifest files. Currently there are 2 partitions that are not using manifest files, and instead have hand written load_info.c files. These partitions are: NS agent trust zone and idle partition. When partition does not have manifest file then its code/data is not gathered together (as there is no manifest to provide needed information). This results in partition code/data being linked directly to SPM. Also code/data may be not correctly aligned (if platform requires special alignment for PSA/APP RoT partitions). For example if platform define custom TFM_LINKER_PSA_ROT_LINKER_DATA_ALIGNMENT, NS agent TZ and idle partitions stacks will not be aligned properly. This is a problem because resulting alignment is not sufficient for the platform, which means that functions that apply protections fail. I see several solutions to this problem: 1. Add alignment to stack of these special partitions. Both the start and the size of the stack should be aligned to satisfy alignment requirements. This is fairly easy fix with small amount of changes. The problem is that code/data of these partitions will still be located in SPM code/data sections which is not ideal solution. I would say this is bare minimum solution, just to make things work. 2. Better solution might be to move these special partitions to now use manifest files. The problem I see is that these partition use special priorities values which are not supported by manifest tool. Also NS Agent TZ uses special PID = 0, which I believe is also not supported by manifest tool. I think this is more time consuming fix but overall this should result in better and easier to understand code. Would be glad to hear a feedback on this topic. Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

1 year, 9 months

2
3
0 0

tfm_hal_memory_symbols

by Chris.Brand＠infineon.com

Hi, I'm looking at https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/?id=df87… which added tfm_hal_memory_symbols.{c|h}, containing tfm_hal_sp_meta_start and tfm_hal_sp_meta_end. The former is used in backend_ipc.c, while the latter is unused. The commit message says "this is the first example of using defined symbols to get memory info" but that commit is over two years old now and there doesn't seem to be a second example. Is there still a plan to move in this direction? If so, can somebody outline what that involves? Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> International Place 13700 V6V 2X8 Richmond Canada www.infineon.com<www.cypress.com> www.cypress.com<http://www.cypress.com> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies> Part of your life. Part of tomorrow. NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.

1 year, 9 months

2
2
0 0

Trusted Firmware-M Technical Overview document

by Joseph Yiu

Hi all, With a lot of helps from the TF-M team, I have prepared a Trusted Firmware-M Technical Overview document, available here: https://www.trustedfirmware.org/blog/TF-M-TechOverview/ In addition to various general concepts about Trusted Firmware-M, this document also introduces several new features in TF-M v1.7. Thanks to the TF-M team for their helps in preparing this document! :-) Regards, Joseph

1 year, 9 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M