December 2024 - TF-M - lists.trustedfirmware.org

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 day, 10 hours

2
2
0 0

Technical Forum call - July 21

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, July 21, 7:00-8:00 UTC (East time zone). Please reply on this email with your proposals for agenda topics. Link to the forum: https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT… Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

2 weeks, 4 days

15
123
0 0

Technical Forum call - Sep 12 (East time zone).

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, Sep 12 at 7:00-8:00 UTC (East time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

11 months, 1 week

2
21
0 0

FW: Weird behavior of Clang linker

by Bohdan.Hunko＠infineon.com

Hi Just forwarding older private discussion to mailing list to make it publicly available. 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: Antonio De Angelis <Antonio.DeAngelis(a)arm.com> Sent: Thursday, December 14, 2023 15:57 To: Mazurak Roman (CSS ICW SW FW 3) <Roman.Mazurak(a)infineon.com>; Anton Komlev <Anton.Komlev(a)arm.com>; Hunko Bohdan (CSS ICW SW FW 3) <Bohdan.Hunko(a)infineon.com> Subject: Re: Weird behavior of Clang linker 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 Roman, I tried to look in the ELF spec that I could find by googling, but what I can find online doesn't mention the topic of alignment requirements at all other than a brief mention of how the base address and align requirements must be coherent. How the requirement on alignment propagates from sections to execution regions to load regions is still something that I am trying to understand as I can't find an exhaustive description. The info I shared below stem from a personal conversation that I had with the compiler team internally here in Arm, I have now asked for a reference, will revert back to you in case I get one. [cid:0aef50f0-9105-480f-8090-06cfaa06b8d3] Only explicit mention of alignment that I could find is in the armlink manual in section 3.3.3. [cid:ef5c45ef-7d67-433c-9aba-b8fd7cf0d1c0] The suggestion from the compiler team are as I mentioned: 1. just disable the strict checks on alignment (i.e. the linker will be then allowed to add padding as required to meet the constraint imposed by the base address of the load region and the ALIGN attributes, by suppressing the diagnostic or using --legacyalign (on a side note, I believe this is the default behaviour on GCC linker for example) 2. rewrite the scatter file to have all the input sections without alignment requirements in the output section where the vector reside, and then have another output section just after the first output section (i.e. with base address +0) to put all the other input sections with increased alignment. As a side note, the suggestion is to also align base addresses of sections using AlignExpr(+0, 4096) (for example, to align to 0x1000) rather than forcing ALIGN attributes. Note that this shouldn't be too complex to attain point 2 but it is something that at the moment we can't work on, but happily merge it in if you're willing to provide a patch for it. Your suggestion of having multiple output section is as well doable, but probably enough to have two of them. Will get back to you in case I get some more reference about how the alignment requirements in ELF propagate from input section to output sections just to confirm on the spec itself. Hope this helps, please let me know if any questions! Thanks, Antonio ________________________________ From: Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@infineon.com> <Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@infineon.com>> Sent: Thursday, December 14, 2023 13:37 To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com<mailto:Antonio.DeAngelis@arm.com>>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com> <Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>> Subject: RE: Weird behavior of Clang linker Hi Antonio, We have a use case when output section has following list of input sections: * Vectors with alignment by 0x400. * Partitions sections with alignment by 0x1000. As result output section alignment is 0x1000 and address is incorrect. So, probably it’s necessary to create a separate output section for each input section. Can you share a link to ELF specification with requirements for output section alignment? Best regards, Roman. From: Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Wednesday, December 13, 2023 18:56 To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Hunko Bohdan (CSS ICW SW FW 3) <Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>> Subject: [TF-M] Re: Weird behavior of Clang linker 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, For reference, this is due to armlink being strict on following the ELF specification for which the region alignment is derived as the maximum alignment of the input sections. You can relax this requirement with armlink by either using the --legacyalign option (although it's being deprecated) or suppressing the diagnostic --diag_suppress=6244. In the future, we could try to reorganize the scatter file for the armclang toolchain to avoid using directly ALIGN attributes and align the base address of the execution regions using AlignExpr() instead, but even with this strategy, any alignment requirement which stems from using .aligned directive in assembly or attribute __ ((aligned)) attributes will influence the input sections alignment, hence it will require a deeper restructuring of the scatter file, possibly moving sections with increased alignment in a separate load region just after LR_CODE which must have a base address that forces a natural alignment. Hope this helps. Thanks, Antonio ________________________________ From: Bohdan.Hunko--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Monday, December 11, 2023 13:39 To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Re: Weird behavior of Clang linker Hi Anton, Here is the version I am using: $ armclang --version Product: Arm Development Studio Gold Edition 2020.1 Component: Arm Compiler for Embedded 6.19 Tool: armclang [5e73cb00] Target: unspecified-arm-none-unspecified 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: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Sent: Monday, December 11, 2023 15:34 To: Hunko Bohdan (CSS ICW SW FW 3) <Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: Weird behavior of Clang linker 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, What is Clang version you are using? Thanks, Anton From: Bohdan.Hunko--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Monday, December 11, 2023 12:58 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Weird behavior of Clang linker Hi all, Our platform uses 4KBs alignment in linker files (as this is the requirement of our protection HW). For this reasons I have introduced tfm_s_linker_alignments.h. Everything works fine with GCC but we have a problem with Clang. The problem is that Clang requires LR_CODE to have same alignment as other sections inside of it. Following are the steps to reproduce the issue: 1. Set TFM_LINKER_DEFAULT_ALIGNMENT to 0x1000 in tfm_s_linker_alignments.h 2. Build AN521 with following command line cmake -S . -B build_an521 -DTFM_PLATFORM=arm/mps2/an521 -DTFM_TOOLCHAIN_FILE=./toolchain_ARMCLANG.cmake Expected result: Everything works fine Actual result: Error: L6244E: Load region LR_CODE address (0x10080400) not aligned on a 4096 byte boundary. This error is weird because there is no explicit alignment assigned to LR_CODE region. Would appreciate a help on this as it is a blocking issue for us. 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> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

1 year, 7 months

2
2
0 0

FPU S16-S31 registers

by Roman.Mazurak＠infineon.com

Hi all, We found the problem with FPU S16-S31 registers if FPU is enabled and compiler uses S16-S31 FPU registers on CM33 non-secure code with TZ agent. SPM doesn't save/restore S16-S31 registers properly nor by PendSV neither by FLIH SVC handler. I created a patch for this problem: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/34202 The second problem I found is related to lazy stacking. It's possible that float point context will be stacked by MCU when FLIH is switching to/from background thread after a new boundary is applied. As result it's possible that the non-privileged code will no have access to PSP stack of suspended partition because a new MPU settings are applied. Please review a patch for this problem: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/34203 Regards, Roman.

1 year, 10 months

2
2
0 0

Re: Backwards compatibility of Protected Storage implementation (TF-M 1.8.1 -> 2.1.1)

by FLOC'H Tanguy

Hello, We are facing the same compatibility break issues, during a TF-M 1.7.0 -> 2.1.0 migration. - About the problem [1] (commit ffd13c3) Is there any plan to implement a mechanism, to migrate old Protected Storage objects, to the new format? - About the problem [2] (client id). There is also a compatibility break, on keys stored in Internal Trusted Storage (ITS). A key generated from NS, with TF-M 1.7.0, can not be read anymore after TF-M 2.1.0 migration (psa_key_attributes returns PSA_ERROR_INVALID_HANDLE). Changing client_id_limit from value -0x3c000000 to -1 makes old keys available. Is there a cleaner option, to support backward compatibility with keys created with client id = -1? Best regards, T. FLOC'H ________________________________ This electronic message and its attachments are confidential and transmitted for the exclusive use of their addressee. Should you receive this message by mistake, you are not authorized to use it for any purpose whatsoever; please delete it and notify the sender at once. LACROIX reserves the right to initiate any legal proceedings against any individual and organization in case of unauthorized use, without prejudice to possible criminal sanctions. ________________________________ Ce message et ses pièces jointes sont confidentiels et exclusivement transmis à l'usage de leur destinataire. Si vous recevez ce message par erreur, vous n’êtes pas autorisés à en faire une quelconque utilisation ; merci de le détruire et d'en avertir immédiatement l'expéditeur. LACROIX se réserve le droit de poursuivre toute entité, personne physique ou morale qui en ferait un usage non autorisé, sans préjudice d'éventuelles sanctions pénales.

1 year, 10 months

2
2
0 0

connection-based MMIOVEC

by Quach, Brian

Hi, I am trying to use connection-based (instead of SFN) Crypto service with MMIOVEC, but I noticed that iovec_status is not automatically cleared so the second psa_call causes a TFM panic due to detection of a previously mapped IOVEC. FF spec says: [cid:image001.png@01DB3B6B.1D4E93F0] In tfm_crypto_call_srv(), I see the output vecs are unmapped but not the input vectors. Should the inputs be unmapped here as well? (psa_attest_get_token also does not unmap input vecs) status = tfm_crypto_init_iovecs(msg, in_vec, in_len, out_vec, out_len); if (status != PSA_SUCCESS) { return status; } tfm_crypto_set_caller_id(msg->client_id); /* Call the dispatcher to the functions that implement the PSA Crypto API */ status = tfm_crypto_api_dispatcher(in_vec, in_len, out_vec, out_len); #if PSA_FRAMEWORK_HAS_MM_IOVEC == 1 for (i = 0; i < out_len; i++) { if (out_vec[i].base != NULL) { psa_unmap_outvec(msg->handle, i, out_vec[i].len); } } #else /* Write into the IPC framework outputs from the scratch */ for (i = 0; i < out_len; i++) { psa_write(msg->handle, i, out_vec[i].base, out_vec[i].len); } Currently, to clear the connection's iovec_status, I have to call psa_close() after every psa_call() and reconnect with psa_connect() before the next psa_call() which adds overhead. Is this behavior of not automatically clearing iovec_status for connection-based services by design? As an alternative to calling psa_unmap_invecs(), I was wondering if spm_get_connection()/spm_get_idle_connection() could be modified with the following workaround to avoid needing to close/connect: #if CONFIG_TFM_CONNECTION_BASED_SERVICE_API == 1 connection = handle_to_connection(handle); if (!connection) { return PSA_ERROR_PROGRAMMER_ERROR; } if (spm_validate_connection(connection) != PSA_SUCCESS) { return PSA_ERROR_PROGRAMMER_ERROR; } /* WORKAROUND */ #if PSA_FRAMEWORK_HAS_MM_IOVEC connection->iovec_status &= 0xFFFF0000; // Clear status of input vecs #endif /* Validate the caller id in the connection handle equals client_id. */ if (connection->msg.client_id != client_id) { return PSA_ERROR_PROGRAMMER_ERROR; } /* * It is a PROGRAMMER ERROR if the connection is currently * handling a request. */ if (connection->status != TFM_HANDLE_STATUS_IDLE) { return PSA_ERROR_PROGRAMMER_ERROR; } if (!(connection->service)) { /* FixMe: Need to implement a mechanism to resolve this failure. */ return PSA_ERROR_PROGRAMMER_ERROR; } #else Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

1 year, 11 months

2
10
0 0

Re: Backwards compatibility of Protected Storage implementation (TF-M 1.8.1 -> 2.1.1)

by Miika Karanki

Hi Anton and Chris, Thank you for your replies. I have TFM_NS_MANAGE_NSID set to off. That does not prevent client_id translation to happen. `tfm_nspm_get_current_client_id` seems to do translation unconditionally here: https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git…. But as said, setting client_id_limit in code to -1 helps. Maybe there could be additional configuration #define whether to do translation when TFM_NS_MANAGE_NSID is off. Transition approach to convert the old PS data format to new one on the flash when reading data in new format fails sounds reasonable assuming there's no security problems involved in retrying to read the objects using the old format after a failure. Probably not. It anyways sounds better than supporting the old one "forever". At least to me, being able to do that transition would require a bit of learning what exactly was the old and what is the new layout. If there's some material in addition to source code, I'd be happy to check that. -Miika ke 27.11.2024 klo 23.01 Chris.Brand--- via TF-M ( tf-m(a)lists.trustedfirmware.org) kirjoitti: > Hi Miika, > > > > Unfortunately there have been a couple of changes to the way that PS data > is stored in flash. I hope that we are getting better at considering > backwards compatibility. In general I think that whenever we do introduce a > change like this, we need to ensure that data stored with the old layout > can still be read by newer code. > > > > I believe the patch that you’ve identified was part of the work to make PS > encryption optional. Looking at it now, I don’t see that the layout was a > necessary part of that work. Unfortunately, we’re now in a position where > there could be PS data stored on devices in this new format, so just > reverting that part of that patch would cause other problems. > > > > The bad news is that there’s another stored format change post-v2.1.1. The > good news is that we did think about existing data and introduced a build > option to read the old format. > > > > One solution to your problem would be similar to > https://github.com/TrustedFirmware-M/trusted-firmware-m/commit/e8d48d78c166… > - a build option to support reading the old format, with stores then using > the new format. Another option would be to introduce the 1.8.1 format as an > alternative implementation i.e. a second struct inside union ps_crypto_t > and provide the 1.8.1 code as well as the current code (this would mean > picking a storage format at build time and using it forever). > > > > Regarding the client_id. You’re correct that the client_id is used as a > kind of access control (the client_id and UID together identify the stored > object). Yes, there was a major change to the way that client_ids are used, > with the mapping being added. Do you have TFM_NS_MANAGE_NSID set to ON? I > believe that if it is set to OFF then -1 is used inside TF-M to represent > all non-secure clients, which sounds like it may be what you need. > > > > Chris >

1 year, 11 months

3
2
0 0

Coding style update

by Antonio De Angelis

Hi all, just to point out that the coding guidelines are being updated to reflect feedback received over the years about the point of variable declaration. The majority of the code already follows this style, changing the guidelines to avoid further confusion. …/coding_guide.rst · Gerrit Code Review<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/33807/1/docs…> Please let us know if any feedback. Thanks, Antonio

1 year, 11 months

1
0
0 0

mbedtls 2.25 and 3.6

by Michael Khoyilar

Hi Team I am investigating the move from MbedTLS 2.25 to 3.6, however, our client uses the 2.25 currently (looks like they prefer to stay with it) and I need to provide convincing proof to move to 3.6 considering the upgrade issues that might arise. Any suggestions here that is convincing proof to do the migration to 3.6? I would appreciate your comments. Thanks Michael

1 year, 11 months

2
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M December 2024