- TF-M - lists.trustedfirmware.org

by Anton Komlev

Hello, TF-M OpenCI fails all LAVA tests and all builds are fail consequently, probably because of a new license mechanism. An investigation and problem fixing are ongoing. I will update you when the problem will be resolved. Best regards, Anton

1 year, 6 months

1
1
0 0

Security Vulnerability Notice - Partial tag comparison when using Chacha20-Poly1305 on the PSA driver API interface in CryptoCell enabled platforms

by Antonio De Angelis

Hi Everyone, There is a new security vulnerability discovered on the PSA Driver API for CryptoCell enabled platforms, described as "Partial tag comparison when using Chacha20-Poly1305 on the PSA driver API interface in CryptoCell enabled platforms". Please find the security advisory specific to TF-M and patches that have been developed as per the TrustedFirmware.org security process [1] below : * TF-M Security advisory: TFMV-6: Add cc3xx_partial_tag_compare_on_chacha20_poly1305 advisory (I44bc426f) · Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/22995> * Patch to fix the issue has been already merged on master branch as commit https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/?id=2e82… * TF-Mv1.8.1 will be released in the next days containing the same hotfix Please let us know if you have any comments. Best regards, /Antonio [1] https://developer.trustedfirmware.org/w/collaboration/security_center/report...<https://developer.trustedfirmware.org/w/collaboration/security_center/repor…>

1 year, 6 months

2
1
0 0

Re: Use of auto-generation approach for mbedtls/mbed-crypto driver psa_crypto_driver_wrappers..h file

by Antonio De Angelis

Hi Ruchika, thanks for your email and apologies for the late reply but I did not receive this directly so I am replying only because I was pointed to this. TF-M would really welcome a contribution to move those drivers to the autogen framework. This has not been done yet due to lack of bandwidth on TF-M side. Would like to note that the TF-M builtin key loader driver can't be (maybe, just completely) moved to the autogen framework because it patches some internals of Mbed TLS as well (i.e. you would need to patch the jinja template as well). But the CC3XX driver is absolutely something that we would like to move to the autogen framework without any issue. Thanks, Antonio

1 year, 6 months

2
1
0 0

Upcoming TF-M release heads up.

by Anton Komlev

Hello, We plan to initiate TF-M v2.1.0 release with a feature freeze on April 8th targeting completion before April 28th. Please let me know if there are pending patches critical to be included in this release and shall be merged before the feature freeze. Thanks, Anton

1 year, 6 months

1
1
0 0

TF-M support for Mbed TLS 3.6.0-LTS

by Antonio De Angelis

Hi all, Mbed TLS 3.6.0-LTS has been recently released and we are in the process of upgrading the supported version of TF-M as well. I have prepared three patches (for tests, extras and the main repo) available here for review that need to be merged by the time the release freeze happens (likely this week at some point). From this patch onwards, TF-M will align completely to the PSA Crypto headers shipped by the Mbed TLS project, hopefully solving the issues we have had in the past around header mismatches when both Mbed TLS and TF-M Crypto are integrated into the same environment. For this reason the TF-M project will just hold a copy of the headers (in the interface/include/psa and interface/include/mbedtls directories) and won't accept any contribution to them. Please find the patches available for review under the following Gerrit topic: topic:"mbedtls_3_6_0_alignment" · Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/q/topic:%22mbedtls_3_6_0_alignment%22> Thanks, Antonio

1 year, 6 months

1
0
0 0

Re: Use of auto-generation approach for mbedtls/mbed-crypto driver psa_crypto_driver_wrappers..h file

by Ruchika Gupta

+ tf-m mailing list From: Ruchika Gupta Sent: Friday, April 5, 2024 4:14 PM To: tf-m <"tf-m(a)lists.trustedfirmware.org <tf-m"@lists.trustedfirmware.org>; mbed-tls(a)lists.trustedfirmware.org; security-wg(a)lists.zephyrproject.org Subject: Use of auto-generation approach for mbedtls/mbed-crypto driver psa_crypto_driver_wrappers..h file Hi All, Apologies for the long email. I am adding all the 3 projects (TF-M, mbedTLS and Zephyr) to the mail chain because the issues I discuss below are inter-connected and affect all the three projects. From mbedtls 3.5.0 version, the mbedtls project has migrated to auto-generated psa_crypto_driver_wrappers.h file. https://github.com/Mbed-TLS/mbedtls/blob/development/docs/psa-driver-exampl… https://github.com/Mbed-TLS/mbedtls/blob/development/docs/proposed/psa-driv… On TF-M, mbed-crypto, there are 2 patches for the drivers given below which are still hardcoding their changes and not following the above approach. 1. PSA_CRYPTO_DRIVER_TFM_BUILTIN_KEY_LOADER (0001-Add-TF-M-Builtin-Key-Loader-driver-entry-points.patch) 2. PSA_CRYPTO_DRIVER_CC3XX (0005-Hardcode-CC3XX-entry-points.patch) We at NXP, have migrated our psa crypto wrappers to the above approach using auto-generation. We want to maintain same code base for mbedtls for our SDK's, TFM mbed-crypto as well as align mbedTLS fork in Zephyr. We are increasingly finding it difficult to migrate to newer versions of mbedtls because of hardcoding of above drivers. The problem is specially on the Zephyr front, where in the mbedTLS fork in zephyr these patches from tfm are applied by default. I have queries for all the 3 projects listed below : TF-M --> Can you please let us know what are the plans to migrate these 2 drivers in tfm to the auto-generation approach. If these patches can be migrated to make changes in jinja files rather than hardcoding in psa_crypto_driver_wrappers , things would be much easier to integrate. Is somebody already working on it ? Are you open to accept patches for this change ? mbedTLS --> What is the long term strategy from mbedTLS on this auto-generation ? We still have a lot of hard-coding in .jinja file rather than using drivers.json. Would mbedTLS/new PSA crypto repository start accepting patches for psa wrappers from platforms ? Can the patches which TF-M project maintains be merged in the mbedTLS ? Zephyr --> On Zephyr front, what are the plans to align to this auto-generation approach ? Regards, Ruchika

1 year, 6 months

2
1
0 0

MCUBOOT_SWAP_USING_MOVE vs MCUBOOT_SWAP_USING_SCRATCH

by Tomasz Jastrzębski

Hi All, I apologize for this probably trivial question, but I cannot find out if and why I should use MCUBOOT_SWAP_USING_MOVE or MCUBOOT_SWAP_USING_SCRATCH. Are there any real advantages of move with SCRATCH other than that it requires less flash? - that is, min just one extra sector for all the images vs min one sector per image? Move without scratch seems to provide a better wear balance but still almost all the examples I come across use move with scratch. What am I missing? Kind regards, Tomasz

1 year, 7 months

2
2
0 0

Windows 10 error file name or extension too long

by Michael Khoyilar

Hi all I am new to TF-M and want to know if there is a public forum to post questions or search for answers? I am getting this error under Windows 10 when making clean: make (e=206): The filename or extension is too long Thank you Michael

1 year, 7 months

4
3
0 0

Please unsubscribe

by Kirill Konevets

Unsubscribe me please

1 year, 7 months

3
2
0 0

TF-M Tech forum time update proposal

by Anton Komlev

Hi, Following the forum session today I am sending this separate email asking for your feedback. The recent forums on the East time zone slot are getting quite low attendance, so I am wondering if it still valuable or we want to reschedule it. The potential options I can think of: 1. Keep the current schedule and change nothing. 2. Drop the East time zone slot and leave West time zone slot only for monthly meetings. 3. Reschedule slots for bi-weekly forums on West time zone. 4. Other ideas? Thanks, and please share your opinion in this email thread, Anton

1 year, 7 months

1
0
0 0

NS Client ID mapping for Hybrid Platform

by Mate Toth-Pal

Hi All, As part of the work we are doing for Hybrid Platforms we prepared a patch that makes changes how the Non-Secure Client IDs are handled. When TF-M is run in Hybrid Platform configuration, It has multiple NS agents active the same time. Each of the NS clients (either running in the NSPE the same v8M CPU as SPM, or on the other end of a Mailbox) can have their own way to assign NS Client IDs to clients. To prevent NS clients impersonate other NS clients that are accessing secure services through a different agent, the patch introduces Client ID mapping. For each NS agent partition a range of valid Client IDs is defined in the manifest yaml file. The SPM checks boot time that the ranges don't overlap. The NS agent partitions must make sure that they map incoming client ID's in a way that the output Client ID is always in the range of valid IDs for that NS agent. If an NS agent has multiple mailboxes, it is possible to assign separate ranges for those mailboxes (the range is associated with the Mailbox IRQ in the manifest yaml). Please find the patch here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/26947 Any questions or comments are welcome! Best Regards, Mate

1 year, 7 months

1
0
0 0

Nordic nRF9160 bootloader gets stuck because of undefined function

by Boeckmann, Lena

Hi folks, I tried running a minimal example on the nRF9160dk. In `boot_hal_bl2.c` the following code is executed: #ifdef FLASH_DEV_NAME result = FLASH_DEV_NAME.Uninitialize(); if (result != ARM_DRIVER_OK) { while(1) {} } #endif /* FLASH_DEV_NAME */ For the Nordic boards `Uninitialize` is not implemented (see `Driver_Flash.c`): ARM_DRIVER_FLASH Driver_FLASH0 = { .GetVersion = NULL, .GetCapabilities = ARM_Flash_GetCapabilities, .Initialize = ARM_Flash_Initialize, .Uninitialize = NULL, .PowerControl = NULL, .ReadData = ARM_Flash_ReadData, .ProgramData = ARM_Flash_ProgramData, .EraseSector = ARM_Flash_EraseSector, .EraseChip = NULL, .GetStatus = NULL, .GetInfo = ARM_Flash_GetInfo }; This leads to a non-zero value being stored in `result` and my program ends up getting stuck in the while loop. Is it possible to fix that? Kind regards, Lena

1 year, 7 months

1
0
0 0

Re: Scheduling bug

by Roman.Mazurak＠infineon.com

Hi Ken, I tested with 2.0.0 release. There are my conclusions. tfm_arch_set_context_ret_code set result (for psa_wait, ...) by using SP stored in sp member of context_ctrl_t structure. It means that before calling tfm_arch_set_context_ret_code TF-M should update SP for thread (partition). thrd_next update result by calling tfm_arch_set_context_ret_code, if query_state_cb (pointing to query_state implemented by backend_ipc.c) returns THRD_STATE_RET_VAL_AVAIL. For all partition except active (interrupted by PendSV) context (values in context_ctrl_t) is correct. But context is invalid for active partition, because it is updated by PendSV after exit from ipc_schedule and thrd_next. As result call for psa_wait would fail if some secure IRQ will update signals_asserted after tfm_spm_partition_psa_wait and before PendSV will call thrd_next. SLIH interrupt can assert such signal (call to backend_assert_signal) in spm_handle_interrupt. I made a simple fix: diff --git a/secure_fw/spm/core/backend_ipc.c b/secure_fw/spm/core/backend_ipc.c index 3a968a3..c8b0742 100644 --- a/secure_fw/spm/core/backend_ipc.c +++ b/secure_fw/spm/core/backend_ipc.c @@ -454,9 +454,14 @@ /* Protect concurrent access to current thread/component and thread status */ CRITICAL_SECTION_ENTER(cs); - pth_next = thrd_next(); p_curr_ctx = (struct context_ctrl_t *)(CURRENT_THREAD->p_context_ctrl); + /* Update SP for current thread, so tfm_arch_set_context_ret_code can use up to date + * value of stack context to return value via R0.*/ + p_curr_ctx->sp = __get_PSP() - sizeof(struct tfm_additional_context_t); + + pth_next = thrd_next(); + AAPCS_DUAL_U32_SET(ctx_ctrls, (uint32_t)p_curr_ctx, (uint32_t)p_curr_ctx); p_part_curr = GET_CURRENT_COMPONENT(); Regards, Roman. From: Bohdan.Hunko--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Wednesday, November 8, 2023 22:22 To: Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd(a)arm.com<mailto:nd@arm.com> Subject: [TF-M] Re: Scheduling bug Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi Ken, I was using 1.8.0 Release Looks like this issue was fixed in new design although we would like to test it and confirm this when we migrate to newest release. We will get back on this to you. 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> From: Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Tuesday, November 7, 2023 03:58 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Re: Scheduling bug Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi Bohdan, Can you share us the version you are working on? Looks like the patch is based on a previous version of TFM, and this issue is resolved in the latest code base. The reason to do such abstraction is just because of such similar issues - the logic was coupled tightly because of synching the partition status, thread status and context update which caused maintenance confusion and effort. And we refactored this part to decouple the logic: SPM: Add STATUS_NEED_SCHEDULE to manage scheduler (21054) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/21054> Hope this helps, thanks. /Ken From: Bohdan.Hunko--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Monday, November 6, 2023 10:01 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Scheduling bug Hi There seem to be scheduling bug we have found in SPM. This bug is related to handling of interrupts that arrives during SVC call and assert signed for partition. Steps to reproduce: 1. Call psa_wait() from partition (e.g. mailbox partition) 2. During execution of SVC handler generate Interrupt that asserts signal of that partition (e.g. mailbox partition signal ) (adding long delay in SVC handler or adding breakpoint in SVC handler helps to easier reproduce this ) 3. Following sequence happens: * Mailbox IRQ has lower priority than SVC thus SVC is not preempted. * SVC sees that mailbox partition is blocked (as it is waiting for signal and no signals are pending) * SVC triggers pendSV i. Mailbox IRQ and pendSV are both pending * Mailbox IRQ has higher priority than pendSV thus Mailbox IRQ is executed * Mailbox IRQ calls spm_handle_interrupt i. Signal is asserted thus spm_handle_interrupt in thrd_next calls query_state_cb which returns THRD_STATE_RET_VAL_AVAIL and thus tfm_arch_set_context_ret_code is called ii. tfm_arch_set_context_ret_code sets return code using OLD value of partition PSP (as it was never updated, as it is updated in PendSV) * Mailbox IRQ return, pendsv is started and it runs mailbox partition i. Mailbox partition has 0 as signal because return value was written to wrong location is stack Patch I have attached to the mail solves this problem for us BUT it seems more like a workaround than a proper fix( Anyways it would be nice to have this problem review by SPM experts and have proper fix (maybe we have other places with same problem...) 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, 7 months

2
3
0 0

SPM thread and FLIH

by Roman.Mazurak＠infineon.com

Hi all, It seems that on v2.0 there is a problem with FLIH handling during execution of SPM thread. 1. A partition #1 is running with unprivileged attribute (CONTROL.nPRIV = 1). 2. It requests PSA API (for example psa_call). 3. psa_call is serviced via SVC. prepare_to_thread_mode_spm schedules handling of psa_call in SPM thread mode (by prepare_to_thread_mode_spm). 4. prepare_to_thread_mode_spm saves CONTROL to saved_control. Than set CONTROL.nPRIV = 0 (privileged for SPM thread). 5. Exit from SVC starts execution of tfm_spm_client_psa_call in SPM thread (privileged). 6. SPM thread is interrupted by FLIH IRQ. 7. FLIH IRQ handler calls spm_handle_interrupt. 8. spm_handle_interrupt switches boundary to prepare environment for FLIH handler (partition #2) and schedules execution of FLIH handler. 9. FLIH handler is executed. 10. tfm_flih_return_to_isr is called on exit from FLIH handler. It restores boundary of partition #1 and set CONTROL.nPRIV = 1. Than returns to FLIH IRQ handler. 11. FLIH IRQ handler exit to SPM thread that has been interrupted on step #6. 12. SPM thread have no enough permissions, because it's running with CONTROL.nPRIV equal to 1 (unprivileged). So, processing environment is unprivileged and tfm_spm_client_psa_call fails on accessing restricted resource. Does my understanding correct? If yes it means that we should fix exit from FLIH to SPM thread. Regards, Roman.

1 year, 7 months

3
5
0 0

Adding platform support for ArmChina Alcor AN557 MPS3 board

by jidong.mei＠armchina.com

Hi I'm working on Adding Platform support for ArmChina Alcor AN557 MPS3 FPGA board . The code has been passed tfm_regression_test on AN557 fpga image and now submit to TF-M git repo. See: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/27267 Could you have a code review on these code ? Any comments and suggestion are welcomed. Thank you! B,R Jidong

1 year, 7 months

1
0
0 0

New TF-M maintainer

by Anton Komlev

Hi Everyone, I am glad to announce the new maintainer of TF-M project: * Antonio de Angelis aka adeaarm Antonio.deAngelis(a)arm.com><mailto:Antonio.deAngelis@arm.com%3e%60> Antonio was with TF-M from the very beginning being one of the project founders. Thank you, Antonio, for agreeing to maintain the project. All the best, Anton

1 year, 7 months

1
0
0 0

Image verification by 'untrusted client'

by Tomasz Jastrzębski

Is TFM-M currently able to verify the signature of the image downloaded by the 'untrusted client'? I mean, are there needed methods exposed to 'untrusted app'? If so, what methods need to be used? Kind regards, Tomasz

1 year, 7 months

1
0
0 0

tf-m main branch (latest commit) compiler error ,when build regression_test for corstone300/an547

by jidong.mei＠armchina.com

Hi I encounter a compile error , with latest main branch tf-m code. Code version : "commit 66c8eada12737f5cf6818ea84739f30ca275437d (HEAD -> main, origin/main, origin/HEAD) Author: Raef Coles <raef.coles(a)arm.com>" Build targert : corstone300/an547 regression_test Build command : cmake -S spe -B build_spe -DTFM_PLATFORM=arm/mps3/corstone300/an547 -DCONFIG_TFM_SOURCE_PATH=<tf-m_path> -DTFM_TOOLCHAIN_FILE=<tf-m_path>/toolchain_GNUARM.cmake -DTEST_S=ON -DTEST_NS=ON -DCMAKE_BUILD_TYPE=Debug & cmake --build build_spe -- install (these command fellow the build_test documentation : https://tf-m-user-guide.trustedfirmware.org/building/tests_build_instructio…) Compile error : "trusted-firmware-m/platform/ext/target/arm/mps3/corstone300/an547/cmsis_drivers/Driver_Flash.c:23:10: fatal error: tfm_hal_device_header.h: No such file or directory #include "tfm_hal_device_header.h" " Could you help to fix this issue. B,R Jidong

1 year, 8 months

3
2
0 0

ITS encryption

by Quach, Brian

Hi, It appears that ITS encryption would be required for PSA Certified Level 3. I'm seeing that this would required a platform specific HAL implementation. Is there some reason PSA Crypto APIs were not used like they were for attestation? Encryption in ITS ================= The ITS can optionally be configured to encrypt the internal trusted storage data. To support encryption in ITS the target platform must provide an implementation of the APIs defined in ``platform/include/tfm_hal_its_encryption.h``:: enum tfm_hal_status_t tfm_hal_its_aead_generate_nonce(uint8_t *nonce, const size_t nonce_size); enum tfm_hal_status_t tfm_hal_its_aead_encrypt( struct tfm_hal_its_auth_crypt_ctx *ctx, const uint8_t *plaintext, const size_t plaintext_size, uint8_t *ciphertext, const size_t ciphertext_size, uint8_t *tag, const size_t tag_size); enum tfm_hal_status_t tfm_hal_its_aead_decrypt( struct tfm_hal_its_auth_crypt_ctx *ctx, const uint8_t *ciphertext, const size_t ciphertext_size, uint8_t *tag, const size_t tag_size, uint8_t *plaintext, const size_t plaintext_size); Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

1 year, 8 months

3
5
0 0

Build without re-downloading packages?

by Tomasz Jastrzębski

Hi All, Since ST platform seems to be supported only passively, I try to adapt tf-m for the new ST U5Axx and U5Gxx MPUs with 4MB flash on my own. It does not come easy since some things are hardcoded and new HAL version is required while breaking HAL changes have been introduced, but this is not the reason why I make this post. Is there any easy way, I mean, some cmake switch, which would allow for a full rebuild without redownloading the required packages? Since clean rebuild from scratch takes time and I need to do it frequently while my Internet connection currently is not super-fast and stable such option would be the most helpful. Kind regards, Tomasz

1 year, 8 months

2
1
0 0

Re: Attest token v2.0 in psa-arch-tests

by Maulik Patel

Hello Bohdan The PSA token spec v2.0 is still in draft and hence is not yet supported by the psa-arch-tests. I am not aware of the specific plan/timelines, but could you please contact psa-arch-tests team to know details? Best Regards, Maulik ________________________________ From: tf-m-request(a)lists.trustedfirmware.org <tf-m-request(a)lists.trustedfirmware.org> Sent: 27 February 2024 12:00 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: TF-M Digest, Vol 64, Issue 12 Send TF-M mailing list submissions to tf-m(a)lists.trustedfirmware.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to tf-m-request(a)lists.trustedfirmware.org You can reach the person managing the list at tf-m-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TF-M digest..." Today's Topics: 1. Re: Attest token v2.0 in psa-arch-tests (Bohdan.Hunko(a)infineon.com) ---------------------------------------------------------------------- Message: 1 Date: Mon, 26 Feb 2024 10:50:38 +0000 From: <Bohdan.Hunko(a)infineon.com> Subject: [TF-M] Re: Attest token v2.0 in psa-arch-tests To: <tf-m(a)lists.trustedfirmware.org> Cc: Kostiantyn.Tkachov(a)infineon.com, Roman.Mazurak(a)infineon.com, Hennadiy.Kytsun(a)infineon.com Message-ID: <be7dcff9aa504e3f894b7f4fd263512d(a)infineon.com> Content-Type: multipart/alternative; boundary="_000_be7dcff9aa504e3f894b7f4fd263512dinfineoncom_" Hi all, Any updates on 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> From: Bohdan.Hunko--- via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Monday, February 19, 2024 15:24 To: tf-m(a)lists.trustedfirmware.org Cc: Tkachov Kostiantyn (CSS ICW SW FW) <Kostiantyn.Tkachov(a)infineon.com>; Mazurak Roman (CSS ICW SW FW 3) <Roman.Mazurak(a)infineon.com>; Kytsun Hennadiy (CSS ICW SW FW 3) <Hennadiy.Kytsun(a)infineon.com> Subject: [TF-M] Attest token v2.0 in psa-arch-tests Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi all, I was trying to run PSA arch tests for INITIAL_ATTESTATION and have some problems with them. Our platform uses version 2.0 of PSA token spec (ATTEST_TOKEN_PROFILE_PSA_2_0_0) - https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-20.txt but psa arch tests does not seem to support it. Am I correct that psa-arch-tests does not support v2.0 of attest token? If yes, then how do I select v2.0 of attest token? If no, then is there a plan to support v2.0 of attest token in psa-arch-tests? If so then what is a release date for that? 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, 8 months

1
0
0 0

Attest token v2.0 in psa-arch-tests

by Bohdan.Hunko＠infineon.com

Hi all, I was trying to run PSA arch tests for INITIAL_ATTESTATION and have some problems with them. Our platform uses version 2.0 of PSA token spec (ATTEST_TOKEN_PROFILE_PSA_2_0_0) - https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-20.txt but psa arch tests does not seem to support it. Am I correct that psa-arch-tests does not support v2.0 of attest token? If yes, then how do I select v2.0 of attest token? If no, then is there a plan to support v2.0 of attest token in psa-arch-tests? If so then what is a release date for that? 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, 8 months

1
1
0 0

Unable to determine default CMAKE_INSTALL_LIBDIR directory

by Quach, Brian

Hi, I'm seeing this warning when running cmake from a conan pkg: `/home/brian/.conan/data/cmake/3.21.3-0/library-msp/ga/package/be241241e9d4718e5bab4eb33935bbb69606bb0c/bin/cmake -S . -B build -DTFM_PLATFORM=arm/mps2/an521`. Does anyone know how to fix it? I see the language is set by `project("Trusted Firmware M" VERSION ${TFM_VERSION} LANGUAGES C CXX ASM)`. Per-partition files done: CMake Warning (dev) at /home/brian/.conan/data/cmake/3.21.3-0/library-msp/ga/package/be241241e9d4718e5bab4eb33935bbb69606bb0c/share/cmake-3.21/Modules/GNUInstallDirs.cmake:236 (message): Unable to determine default CMAKE_INSTALL_LIBDIR directory because no target architecture is known. Please enable at least one language before including GNUInstallDirs. Call Stack (most recent call first): build/lib/ext/mbedcrypto-src/CMakeLists.txt:42 (include) This warning is for project developers. Use -Wno-dev to suppress it. Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

1 year, 8 months

2
1
0 0

There are many kinds

by bpqp9ny2＠nqmo.com

Car Mishaps is often harrowing experiences, leaving victims addressing physical injuries, emotional trauma, and financial burdens. In this sort of demanding occasions, owning the right lawful representation might make all the primary difference. When you are in Austin, Texas, and end up wanting legal support following a car accident, https://www.canadatopescorts.com

1 year, 8 months

1
0
0 0

STM32l562e_dk platform is excluded from LAVA tests being a blocker for TF-M builds

by Anton Komlev

Hello, STM32l562e dk platform is timing out in LAVA tests which fails all TF-M builds. The platform was excluded from tests temporarily to enable normal development progress. Best regards, Anton

1 year, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M