Hi,
Why should the sha_1 not be supported at secure test suite?
Our soc has a cypto accelerator, that supports sha_1/224 and so on. The following is the detail.
File:
\tfm\lib\ext\tfm_test_repo-src\test\secure_fw\suites\crypto\secure\crypto_sec_interface_testsuite.c
Function:
static void tfm_crypto_test_1010(struct test_result_t *ret)
{
psa_unsupported_hash_test(PSA_ALG_SHA_1, ret);
}
Thanks and best regards,
zhilei.wang
bekencorp
Hi,
I'd like to propose presenting some of the work we've done around
"Confidential AI" with TF-M and Zephyr during the next TF Tech Forum call.
I think I'll probably need 30 minutes or so, and can take some questions
after time and agenda permitting.
If you're not familiar with the project, it's an attempt at trying to
determine how open standards and open source software (Zephyr, TF-M,
MCUBoot, etc.) can be used together in a practical, end-to-end security use
case ... in this case, running inference on sensor data in the secure
partition, and transmitting sensitive data from S to NS to the cloud.
Relevant repos are here, but of course I'll try to give a meaningful
overview of all of this during the call since the project has several
related components:
- https://github.com/Linaro/zephyr_confidential_ai
- https://github.com/Linaro/lite_bootstrap_server
Thanks and best regards,
Kevin Townsend
Tech Lead - LITE, Vertical Technologies
Linaro.org │ Open source software for ARM SoCs
Hi,
Is it correct that CONFIG_TFM_FP_ARCH_ASM is 'empty string' when using FP_ARCH_FPV5_SP_D16? I'm wondering if it should be set to "FPv5-SP"
############################## FP Arch #########################################
config FP_ARCH_FPV5_D16
def_bool n
help
FPv5-D16
config FP_ARCH_FPV5_SP_D16
def_bool n
help
FPv5-SP-D16
config CONFIG_TFM_FP_ARCH
string
default "fpv5-d16" if FP_ARCH_FPV5_D16
default "fpv5-sp-d16" if FP_ARCH_FPV5_SP_D16
default ""
config CONFIG_TFM_FP_ARCH_ASM
string
default "FPv5_D16" if FP_ARCH_FPV5_D16
default ""
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
Hello,
The changes made for the TF-M v1.8.0 are merged back to the master branch.
To allow that, Corstone-1000 platform was temporarily excluded from OpenCI tests because the platform changes in the release branch conflicted with changes in the master, made in parallel. The platform will be back under test immediately after the conflict resolution.
Corstone-1000 platform builds and runs correctly under v1.8.0 tag.
Thanks,
Anton
Hello,
I am pleased to announce the release of TF-M v1.8.0<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tag/?h=TF-Mv1.8…>.
New major features are:
* TF-M eRPC Test framework 1 is integrated.
* TF-M builtin key loader integration is reworked.
* Improved crypto library abstraction from TF-M Crypto service.
* Kconfig system is enhanced and finalized.
* Switch to upstream QCBOR 2.
* Enable PSA Authenticated Debug Access Control (ADAC) 3 support on Musca-B1 platform.
* Support Floating-Point (FP) with Arm Compiler.
* FF-M API uses signals to drive the partition scheduling instead of controlling partition context directly.
* MCUboot upgrade to v1.10.0.
* Mbed TLS upgrade to v3.4.0.
* Refine documentation restructure.
* It is optional to update copyright year in changes. Requirements of copyright note update is updated in Contributing Process.
Please check the release notes<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/relea…> for more information.
The release branch changes will be ported to the main branch shortly.
Many thanks to everyone for contributing, reviewing and supporting this milestone.
Anton
Hello,
For isolation levels > 1, partitions need to SVC for PSA APIs. To improve the efficiency of this call type, the SVC handler needs to be simplified.
Currently, there are several obvious places to be improved:
- Handlers in C have multiple-level function calling;
- There are a couple of checks in the handler routine that can be refined.
And, to take advantage of instruction TBB, the switch/case number needs to be linear - but it is not always stable hence needs to investigate if a handmade function table would be more stable.
The leading patches are here:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/20644
Feel free to comment or reply in this thread.
Thanks.
/Ken
Hi,
We're making some adjustments for the SVC number assignments.
I'd like to collect some feedbacks, especially from downstream platforms that have your own SVC handler because corresponding changes of your SVC numbers are required when these changes were accepted.
Originally, The SVC numbers are categorized by their values, for example, numbers less than 0x40 are PSA API requests and numbers larger than 0x80 are for handler mode.
This is not convenient for adding new SVC because it's not intuitive to find a proper value range.
More importantly, it's easy to create clashes between TF-M and platform SVC by mistake as they are defined in different files.
So, we propose to divide the SVC number bits into different fields for distinguishing different types of SVC.
Please see here<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/20644/1/secu…> for the detailed descriptions.
With these changes, it's much easier to put the SVC numbers in the right range and avoid duplications after setting the bit fields to right values.
Thanks,
Kevin
Is the highlighted line below correct? Or should the angle bracket be at the end like this: $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/../protected_storage>
target_include_directories(tfm_psa_rot_partition_its
PRIVATE
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}>
${CMAKE_BINARY_DIR}/generated/secure_fw/partitions/internal_trusted_storage
PUBLIC
# Required for ps_object_defs.h
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}>/../protected_storage
)
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
Hello everyone,
I need to extend PSA Crypto API by adding a platform specific encryption algorithm/key attribute. For example a vendor specific algorithm named ABC must be added. So, I need that following macro must be included when psa/crypto.h is included.
#define PSA_ALG_ABC ((psa_algorithm_t) 0x08000123)
TF-M provides PSA Crypto interface through includes located in interface/include/psa/crypto*.h. It means that we need to extend TF-M by allowing platform to provide some platform specific crypto header that will be installed in interface folder and included by psa/crypto.h.
1. Is there any activity related to this problem?
2. I'm considering to create a new crypto_config.h that must be generated during build process and which can optionally provide a macro TFM_PLATFORM_CRYPTO_EXTRA. These macro will be used in psa/crypto.h to conditionally include crypto_platform.h - header provided by platform.
Thanks,
Roman.
Hi. We at Nordic are running the TF-M regression and PSA architecture tests on our boards, and we get occasional issues with test output because HW flow control is by default disabled in CMSIS.
To enable HW flow control in the TF-M we must change the call to the CMSIS UART driver.
I've created a change to allows the platform to set any non-default CMSIS configuration, such as HW flow control:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/20374
I'd like to ask all platform maintainers to review this change.
This change must add another define to all supported platforms, the change itself should not cause any difference in actual behavior.
This can be used for other non-default UART configuration in other platforms as well.
-Joakim Andersson
Hi all,
PSA FWU API update to version 1.0 made it easy to support updates of more than 2 images.
To do so platform may define its own FWU_DEVICE_CONFIG_FILE which will contain definitions for all the components.
So it looks like in current implementation FWU service should easily support FWU_COMPONENT_NUMBER > 2 (for example FWU_COMPONENT_NUMBER = 4)
The only place that I see that doesn't support this is secure_fw/partitions/firmware_update/bootloader/mcuboot/tfm_mcuboot_fwu.c file which have following code:
#if (MCUBOOT_IMAGE_NUMBER == 1)
#define MAX_IMAGE_INFO_LENGTH (sizeof(struct image_version) + \
SHARED_DATA_ENTRY_HEADER_SIZE)
#else
#define MAX_IMAGE_INFO_LENGTH 2 * (sizeof(struct image_version) + \
SHARED_DATA_ENTRY_HEADER_SIZE)
#endif
So if MCUBOOT_IMAGE_NUMBER is 4 then MAX_IMAGE_INFO_LENGTH will only account for 2 images. To fix this I propose to change the code to:
#define MAX_IMAGE_INFO_LENGTH MCUBOOT_IMAGE_NUMBER * (sizeof(struct image_version) + \
SHARED_DATA_ENTRY_HEADER_SIZE)
This change will allow platform to support update of more than 2 components (assuming that platforms implementation of bootloader supports that)
So I have few questions:
1. Will such change be accepted upstream? Do you see any problems with this change?\
2. Are there already platforms that support update of more than 2 components?
3. Are there any known problems with supporting update of more than 2 components?
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>
Hi,
The mailbox agent API was proposed before and this time more implementation details are introduced in the document:
Docs: Implementation details for Mailbox Agent API (Ifec409eb) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/20421>
Feel free to comment, and feel free to create implementations for it - remember response to this thread before you do.
Thanks.
/Ken
Hi experts,
Recently we are building uboot with s_veneers.o, and found that we can not jump to tfm. The reason is that the jump addr is wrong when compileing with -pie.
The symbol "tfm_vendor_aes_encrypt_with_hardware_ssk" in s_veneers.o.
$ nm ./drivers/tfm/lib/s_veneers.o | grep tfm_vendor_aes_encrypt_with_hardware_ssk
04008029 A tfm_vendor_aes_encrypt_with_hardware_ssk
Building uboot without cflags -pie, and the last line shows the wrong jump addr 0xf7fc7e61
0c0401f0 <__tfm_vendor_efuse_write_veneer>:
c0401f0: b401 push {r0}
c0401f2: 4802 ldr r0, [pc, #8] ; (c0401fc <__tfm_vendor_efuse_write_veneer+0xc>)
c0401f4: 46fc mov ip, pc
c0401f6: 4484 add ip, r0
c0401f8: bc01 pop {r0}
c0401fa: 4760 bx ip
c0401fc: f7fc7e61 .word 0xf7fc7e61
Building uboot without cflags -pie,and the last line shows the right jump addr 0x04008029.
0c040200 <__tfm_vendor_aes_encrypt_with_hardware_ssk_veneer>:
c040200: b401 push {r0}
c040202: 4802 ldr r0, [pc, #8] ; (c04020c <__tfm_vendor_aes_encrypt_with_hardware_ssk_veneer+0xc>)
c040204: 4684 mov ip, r0
c040206: bc01 pop {r0}
c040208: 4760 bx ip
c04020a: bf00 nop
c04020c: 04008029 .word 0x04008029
The linker flag -pie is default enabled in uboot(for relocation feature), and we need this feature.
Could you please give us some pointers, suggestions or objections about this problem, Thanks!
Hi Antonio,
Thank you for taking the time to help confirm the function, and we've
found out that this error just resulted from
the incorrect initialization of 'operation' before calling PSA APIs, after
fixing this bug, we also got the correct
OKM. Thanks again for your support.
Best Regards,
Poppy Wu
吴偏偏
http://www.mxic.com.cn
Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org>
2023/03/23 21:58
Please respond to
Antonio De Angelis <Antonio.DeAngelis(a)arm.com>
To
"tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>
cc
nd <nd(a)arm.com>
Subject
[TF-M] Re: Please help check the failure of PSA_ALG_HKDF_EXPAND operation
test
Hi,
I have tried the example below on mbed TLS running on an x86 Linux based
host machine, and on the AN521 platform, and in both cases I can get
consistent results, i.e. the value of the okm buffer at the end is:
0x3c, 0xb2, 0x5f, 0x25, 0xfa, 0xac,
0xd5, 0x7a, 0x90, 0x43, 0x4f, 0x64,
0xd0, 0x36, 0x2f, 0x2a, 0x2d, 0x2d,
0x0a, 0x90, 0xcf, 0x1a, 0x5a, 0x4c,
0x5d, 0xb0, 0x2d, 0x56, 0xec, 0xc4,
0xc5, 0xbf, 0x34, 0x00, 0x72, 0x08,
0xd5, 0xb8, 0x87, 0x18, 0x58, 0x65
Which I believe matches the expected output below. Given that your issue
seems to be specific to the stm32l562e_dk platform, which uses its own
crypto accelerator I believe rather than pure software implementation, I
would suggest to have a look at the intermediate steps and compare your
results against the AN521 platform results. You might want to raise this
behaviour to the platform maintainer, as at this stage this seems to me to
be a platform specific issue.
I can only confirm that you are not misusing the PSA Crypto APIs here.
Let me know if I can be of any more help.
Thanks,
Antonio
From: Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Thursday, March 23, 2023 12:51
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Re: Please help check the failure of PSA_ALG_HKDF_EXPAND
operation test
I am going to have a look into this. Thanks for the instructions on how to
reproduce. Might get a while to reply, please bear with me.
Thanks,
Antonio
From: Edward Yang via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Thursday, March 23, 2023 01:36
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Please help check the failure of PSA_ALG_HKDF_EXPAND
operation test
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 --
TF-M mailing list -- tf-m(a)lists.trustedfirmware.org
To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org
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
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
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
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
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.
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>
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>
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.
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