- TF-M - lists.trustedfirmware.org

Another Test from PN

by Prasanth Nair

Another Test from PN

3 months

1
0
0 0

TF-M test message from PN

by Prasanth Nair

TF-M test message from PN

3 months

1
0
0 0

TF-M Test Message

by Shaun Longhorn

All, We've had reports of people being unable to send messages to the TF-M list. If you are one of the people please could you send me a rough time, source address and subject for the failed message. Thanks, Shaun Longhorn Community Manager

3 months

1
0
0 0

test message

by Anton Komlev

This is a test message because an issue with the mailing list was reported.

3 months

1
0
0 0

Issue with absolute paths in exported targets

by Bohdan.Hunko＠infineon.com

Hi all, I have noticed an issue with absolute paths in exported targets: Background: 1. During Secure build some header file paths are added to include directories of tfm_config (and some other targets) – for example TARGET_CONFIG_HEADER_FILE, PROJECT_CONFIG_HEADER_FILE 2. Then tfm_config is exported to install directory and is used in Non-Secure build There are several issues here: 1. In Non-Secure build exported tfm_config uses absolute paths that ware defined during secure build. This is an issue as NS-interface (api_ns folder) may be built on another machine. 2. Also looking into api_ns folder – I don’t see those files being exported (for example TARGET_CONFIG_HEADER_FILE, PROJECT_CONFIG_HEADER_FILE are not exported to api_ns) * Looking into a code I was able to identify at least these defines that are effected (but list may be longer): i. TARGET_CONFIG_HEADER_FILE ii. PROJECT_CONFIG_HEADER_FILE iii. MBEDTLS_PSA_CRYPTO_CONFIG_FILE iv. MBEDTLS_CONFIG_FILE Is there a plan to somehow solve this issue? If so, then what is the schedule on it? Bohdan Hunko Cypress Semiconductor Ukraine LLC Senior Engineer CSS ICW SW INT BFS SFW Mobile: +380995019714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

3 months

1
0
0 0

Updated invitation with note: TF-M Tech forum @ Every 4 weeks from 8am to 9am on Thursday from Thu 27 May 2021 to Wed 31 Dec (BST) (tf-m@lists.trustedfirmware.org)

by Shaun Longhorn

This event has been updated with a note: "The TF-M Technical Forum now runs on a monthly schedule in a time slot chosen to maximize participation based on recent attendance patterns. We recognise that time zones can be challenging, and we continue to review scheduling based on community needs. Everyone is welcome to join, and as always, recordings and notes will be available for those who can’t attend live." Changed: time TF-M Tech forum Every 4 weeks from 8am to 9am on Thursday from Thursday 27 May 2021 to Wednesday 31 Dec United Kingdom Time Location https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9253579… About TF-M Tech forum:This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/==…Topic: TF-M Tech forum - Asia Time Zone FriendlyTime: Nov 12, 2020 07:00 AM Greenwich Mean Time        Every 4 weeks on Thu, until Mar 4, 2021, 5 occurrence(s)        Nov 12, 2020 07:00 AM        Dec 10, 2020 07:00 AM        Jan 7, 2021 07:00 AM        Feb 4, 2021 07:00 AM        Mar 4, 2021 07:00 AMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJYodOyvpz8jGNEc_1ykVap8Zg6oTLqZZSeJ/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT09Meeting ID: 925 3579 4925Passcode: 414410One tap mobile+12532158782,,92535794925# US (Tacoma)+13462487799,,92535794925# US (Houston)Dial by your location        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 669 900 9128 US (San Jose)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        +1 646 558 8656 US (New York)        888 788 0099 US Toll-free        877 853 5247 US Toll-freeMeeting ID: 925 3579 4925Find your local number: https://linaro-org.zoom.us/u/aesS64I7GW Guests Don Harbin - creator tf-m(a)lists.trustedfirmware.org anton.komlev(a)arm.com leonardo.sandoval(a)linaro.org abdelmalek.omar1(a)gmail.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=aDM1OHZtbG0wa2di… Reply for tf-m(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=aDM1OHZtbG0wa2di… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

3 months

1
0
0 0

Synced invitation: TF-M Tech forum @ Every 4 weeks from 8am to 9am on Thursday from Thu 14 Sept 2023 to Wed 31 Dec (BST) (tf-m@lists.trustedfirmware.org)

by Shaun Longhorn

This email keeps the event up to date in your calendar. TF-M Tech forum Every 4 weeks from 8am to 9am on Thursday from Thursday 14 Sept 2023 to Wednesday 31 Dec United Kingdom Time Location https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9253579… About TF-M Tech forum:This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/==…Topic: TF-M Tech forum - Asia Time Zone FriendlyTime: Nov 12, 2020 07:00 AM Greenwich Mean Time        Every 4 weeks on Thu, until Mar 4, 2021, 5 occurrence(s)        Nov 12, 2020 07:00 AM        Dec 10, 2020 07:00 AM        Jan 7, 2021 07:00 AM        Feb 4, 2021 07:00 AM        Mar 4, 2021 07:00 AMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJYodOyvpz8jGNEc_1ykVap8Zg6oTLqZZSeJ/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT09Meeting ID: 925 3579 4925Passcode: 414410One tap mobile+12532158782,,92535794925# US (Tacoma)+13462487799,,92535794925# US (Houston)Dial by your location        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 669 900 9128 US (San Jose)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        +1 646 558 8656 US (New York)        888 788 0099 US Toll-free        877 853 5247 US Toll-freeMeeting ID: 925 3579 4925Find your local number: https://linaro-org.zoom.us/u/aesS64I7GW Guests Don Harbin - creator anton.komlev(a)arm.com leonardo.sandoval(a)linaro.org abdelmalek.omar1(a)gmail.com joanna.farley(a)arm.com tf-m(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

3 months

1
0
0 0

Update to TF-M Technical Forum Scheduling

by Anton Komlev

Hi All, I wanted to inform you about a change to the TF-M Technical Forum meeting schedule. Previously, we held sessions every two weeks, alternating between Eastern and Western-friendly time zones to accommodate our global audience. After reviewing participation patterns we've decided to simplify the schedule to a monthly cadence, with meetings held in a Western-friendly time slot. We hope this update makes participation more predictable and better aligned with current engagement. Everyone is still very welcome to attend, and as always, recordings and notes will be available for those unable to join live. Best regards, Anton

3 months, 1 week

1
0
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

3 months, 1 week

2
21
0 0

TFM_VERSION

by Chris.Brand＠infineon.com

I notice that TFM_VERSION_MANUAL gets set to "2.2.1" in both release/2.2.x and in main. Granted, the hash gets appended to make TFM_VERSION, and there's some reading of git tags involved that can override TFM_VERSION_MANUAL, but it still feels odd that both identify as the "same" version. Perhaps main should be flagged as being the "next" version as soon as the previous version branch has been created? So we would tag main as v2.3.pre or something. Either that or something that identifies as *not* being a regular release. Chris

3 months, 2 weeks

2
1
0 0

IAR + FIH issue

by Bohdan.Hunko＠infineon.com

Hi all, I am trying to build TFM with IAR with TFM_FIH_PROFILE=HIGH and I am facing the issue with the FIH labels. I see following errors: [ 98%] Linking C executable ../bin/tfm_s.axf Error[Li006]: duplicate definitions for "FIH_LABEL_FIH_CALL_END_46_1"; in "main.o(libtfm_spm.a)", and "tfm_hal_platform.o(libtfm_spm.a)" Error[Li006]: duplicate definitions for "FIH_LABEL_FIH_CALL_START_46_1"; in "main.o(libtfm_spm.a)", and "tfm_hal_platform.o(libtfm_spm.a)" Error[Li006]: duplicate definitions for "FIH_LABEL_FIH_CALL_END_35_0"; in "tfm_hal_platform.o(libtfm_spm.a)", and "platform_svc_handler.o(libtfm_spm.a)" Error[Li006]: duplicate definitions for "FIH_LABEL_FIH_CALL_START_35_0"; in "tfm_hal_platform.o(libtfm_spm.a)", and "platform_svc_handler.o(libtfm_spm.a)" I did some investigations and I believe I know the root cause: Looks like __COUNTER__ for IAR is unique only for a translation unit (.c file) - thus when 2 files have FIH call in same line with the same number of FIH calls before - it creates a label which overlaps with labels in other file. For example tfm_hal_platform.c in our case has first FIH CALL in line 46 (which creates label FIH_LABEL_FIH_CALL_END_46_1) but main.c in our code also has first FIH CALL in line 46 which also results in FIH_LABEL_FIH_CALL_END_46_1 label. The question is - how can we solve this issue? Any ideas I can try? 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>

3 months, 3 weeks

2
7
0 0

Upcoming TF-M Minor Releases: v2.1.4 and v2.2.2

by Anton Komlev

Hello, We're preparing two new minor releases: v2.1.4 and v2.2.2. Both releases update TF-M to include MbedTLS v3.6.5, which brings several vulnerability fixes and fix of the bug reported in v2.2.1. Following a successful dry-run test we'll publish Release Candidate (RC1) followed by the final release. As these are minor updates, we don't expect platform-specific testing, assuming the changes are platform-independent and that our CI coverage will be sufficient. However, please feel free to reach out if you have any concerns or foresee any platform impact. Thank you and best regards, Anton

3 months, 3 weeks

1
0
0 0

AI Policy - Guidance on AI-assisted contributions

by Shaun Longhorn

All, Please be aware that today we have published our AI policy with Guidance on AI-assisted contributions. See the full details here: https://www.trustedfirmware.org/aipolicy/ Should you have any questions feel free to raise them. Thanks, Shaun Community Manager

3 months, 4 weeks

1
0
0 0

Re: [Hafnium] Re: Gerrit scheduled maintenance: 8th November 8-12 UTC

by jerome.forissier＠linaro.org

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

4 months

1
0
0 0

Re: Gerrit scheduled maintenance: 8th November 8-12 UTC

by saheer.babu＠arm.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

4 months

3
2
0 0

TF-M with Zephyr port of MCUboot

by Ozer, Sadik

Hi TF-M team, In our product, we intend to use the vanilla MCUboot (specifically the Zephyr port) instead of the version bundled with Trusted Firmware-M (TF-M). Since TF-M is optional for our use case, but MCUboot is a mandatory component, we prefer to decouple the two. Seems there are some provisioning related items that need to be handled in vanilla MCUboot for this type of usage. We would like to know if you foresee any security concerns or risks associated with this approach? Is this an expected of a usage? Any feedback for this type of usage would be appreciated. Thanks Sadik

4 months, 1 week

2
1
0 0

Open CI testing infrastructure is currently experiencing issues

by Anton Komlev

Hello, The Open CI testing infrastructure is currently experiencing issues due to an FVP licensing problem. Image builds remain operational but FVP-based tests are failing, which causes all build jobs to be marked as failed. The Open CI team is actively working to resolve the issue. An update will be shared once normal operation is restored. Thanks, Anton

4 months, 1 week

1
1
0 0

FIH code sharing

by Chris.Brand＠infineon.com

Hi, Currently TF-M and mcuboot have some "common" FIH code (see for example commit 0a74c1ea8a0c0783a2914d87cd2e88b677718a2e that copied fih.{c|h} from mcuboot. There are also multiple copies of fih.h within the TF-M repo (lib/fih/inc and bl2/ext/mcuboot/include). Are there any plans to avoid having copies of that code? Maybe to split the FIH library into its own repo that can be used by both TF-M and mcuboot? Thanks, Chris

4 months, 1 week

2
1
0 0

Question on pka_ec_wrst_smul_scap.c in CryptoCell3xx Runtime

by Sato, Masaki

Hi TFM Developer Forum Organizer, I'm currently integrating the CryptoCell3xx Runtime code for ECDSA hardware acceleration and have a question regarding the implementation. I'm not entirely sure if this is the right list to post to - perhaps it belongs in mbed-tls or psa-crypto instead - so please forgive me and suggest the right list if this is not the appropriate forum. I noticed that the repository contains two variants of pka_ec_wrst_smul: one under no_scap and another under scap, located in /lib/ext/cryptocell-312-runtime/codesafe/src/crypto_api/pki/ec_wrst/. From the filenames and comments, it appears that scap.c is the Side-Channel Attack (SCA)-resistant version, and would therefore be preferred for end-user products where stronger security is prioritized over performance. However, in the current version of pka_ec_wrst_smul_scap.c from the main open-source branch, I found a couple of apparent typos/bugs that cause compilation errors: Line 239: should probably be PkaAddJcbJcb2Mdf(EC_SIGN_REG_XS, EC_SIGN_REG_YS, EC_SIGN_REG_ZS, EC_SIGN_REG_TS, EC_SIGN_REG_XS, EC_SIGN_REG_YS, EC_SIGN_REG_ZS, EC_SIGN_REG_X2, EC_SIGN_REG_T2, EC_SIGN_REG_Z2); (currently missing the leading "P".) Lines 389 and 391: the output parameters are declared as const, which seems incorrect. For example: CCError_t PkaEcWrstScalarMult(const CCEcpkiDomain_t *pDomain, /*!< [in] Pointer to EC domain. */ const uint32_t *scalar, /*!< [in] Pointer to the scalar buffer. */ uint32_t scalSizeInWords, /*!< [in] Size of the scalar in 32-bit words. */ uint32_t *inPointX, /*!< [in] Pointer to input point X coordinate. */ const uint32_t *inPointY, /*!< [in] Pointer to input point Y coordinate. */ const uint32_t *outPointX, /*!< [out] Pointer to output point X coordinate. */ The const qualifier on the output parameters seems unintended and rather for inPointX. Because of these issues, it seems this file might not have been recently reviewed or tested. So, my questions are: 1. Is the CryptoCell312 Runtime actively maintained and tested in a specific branch where these typos/bugs are already fixed? If so, could you please share which branch that is? 2. If not, it seems that CMake currently only selects the no_scap variant. Does this mean the scap variant is not actively maintained or tested, and therefore not recommended for production use due to higher risk? Thanks in advance for your help and clarification. Best regards, Masaki Sato (P.S. I have sent this message from proofpoint TFM list by "Start a new thread" button. However, I don't see a record on the "posting activity" under my account profile nor active discussion list. Pardon me, but I'm a newbie to this forum, so please forgive me to send the same message by email. ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.

4 months, 1 week

3
3
0 0

Gerrit scheduled maintenance: 8th November 8-12 UTC

by saheer.babu＠arm.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

4 months, 2 weeks

1
0
0 0

TF-M v2.3.0 is postponed to Q2 2026

by Anton Komlev

Hello, I would like to inform the community that the TF-M v2.3.0 release has been postponed to April 2026 in order to incorporate the forthcoming PSA-Crypto LTS release, anticipated in Q1 2026. This decision is intended to ensure improved long-term alignment between two projects. I apologize for any inconvenience the delay may cause and appreciate your understanding. Best regards, Anton

4 months, 2 weeks

1
0
0 0

Enable PLATFORM_PSA_ADAC_SECURE_DEBUG

by 김종혁

Hello, I have already poted this. but, i can't find my thread. I’m trying to enable the PLATFORM_PSA_ADAC_SECURE_DEBUG. 1) Platform (arm neoverse RDV3R1 (RSE)) repo init -u https://git.gitlab.arm.com/infra-solutions/reference-design/infra-refdesign… -m <manifest-file-name> -b refs/tags/<RELEASE_TAG> --depth=1 repo sync -c -j $(nproc) --fetch-submodules --force-sync --no-clone-bundle manifest file: pinned-rdv3r1.xml  release tag: refs/tags/RD-INFRA-2025.07.03 2) Enabling the ADAC Parameter \\wsl.localhost\Ubuntu-22.04\home\phillip\251020_ws\tf-m\config\config_base.cmake I changed the parameter from FALSE to TRUE. set(PLATFORM_PSA_ADAC_SECURE_DEBUG      TRUE       CACHE BOOL      "Whether to use psa-adac secure debug.")   3) Build Command phillip@phillip3420:~/251020_ws$ ./build-scripts/build-tf-m.sh -p rdv3r1 -f uefi build 4) Error Message =============================================================================== -- Populating libpsaadac -- Configuring done (0.0s) -- Generating done (0.0s) -- Build files have been written to: /home/phillip/251020_ws/tf-m/cmake_build/rdv3r1/0/lib/ext/libpsaadac-subbuild [1/9] Creating directories for 'libpsaadac-populate' [1/9] Performing download step (git clone) for 'libpsaadac-populate' Cloning into 'libpsaadac-src'... HEAD is now at 819a254 Platform: Fix prototype for crypto_hw_apply_debug_permissions [2/9] Performing update step for 'libpsaadac-populate' -- Already at requested ref: 819a254af6fb5eefdcef194ec85d2c7627451351 [3/9] No patch step for 'libpsaadac-populate' [5/9] No configure step for 'libpsaadac-populate' [6/9] No build step for 'libpsaadac-populate' [7/9] No install step for 'libpsaadac-populate' [8/9] No test step for 'libpsaadac-populate' [9/9] Completed 'libpsaadac-populate' CMake Error at cmake_build/rdv3r1/0/lib/ext/libpsaadac-src/target/trusted-firmware-m/config.cmake:12 (Message):   Platform arm/rse/neoverse_rd/rdv3r1 not supported. Call Stack (most recent call first):   cmake_build/rdv3r1/0/lib/ext/libpsaadac-src/CMakeLists.txt:34 (include) -- Configuring incomplete, errors occurred! +++ handle_error ++++ caller 0 +++ local 'callinfo=93 do_build ./build-scripts/build-tf-m.sh' +++ local script=./build-scripts/build-tf-m.sh +++ local lineno=93 +++ local 'func=93 do_build' +++ func=do_build +++ echo +++ echo -en '\e[1m\e[31mBuild failed: error while running do_build at line ' Build failed: error while running do_build at line +++ echo -en '93 in ./build-scripts/build-tf-m.sh for rdv3r1[rdv3r1]' 93 in ./build-scripts/build-tf-m.sh for rdv3r1[rdv3r1]+++ echo -e '[uefi].\e[0m' [uefi]. +++ echo +++ exit 1 =============================================================================== 5) My opinion TFM_PLATFORM_PATH is "/home/phillip/251020_ws/tf-m/cmake_build/rdv3r1/0/lib/ext/libpsaadac-src/target/trusted-firmware-m/platform/arm/rse/neoverse_rd/rdv3r1" in my workpace. But, in the "/home/phillip/251020_ws/tf-m/cmake_build/rdv3r1/0/lib/ext/libpsaadac-src/target/trusted-firmware-m/platform/arm/rse/" directory, there are only two folders, "common" and "tc". PLATFORM_PSA_ADAC_VERSION should be changed? (The RD-INFRA-2025.07.03 source code use PLATFORM_PSA_ADAC_VERSION as 819a254) I would be grateful for any advice or pointers from anyone familiar with this. Thanks Best Regards Phillip

4 months, 2 weeks

3
2
2 0

TFM fails to compile asm (.s) file for CM55 core

by Bohdan.Hunko＠infineon.com

Hi all, I see that https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/31942 changes the way ASM files are built for Clang, this seems to cause the issues in our build: I am trying to compile following file https://github.com/Infineon/mtb-dsl-pse8xxgp/blob/master/pdl/drivers/source… for cortex-m55<https://github.com/Infineon/mtb-dsl-pse8xxgp/blob/master/pdl/drivers/source…> CPU but I get following errors: armclang: error: armasm does not support CPU 'cortex-m55' armclang: error: armasm does not support FPU 'unknown' cmd.txt shows full compile command for this file. I suppose this is because -masm=armasm does not support CM55 core? Any ideas how 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>

4 months, 4 weeks

2
4
0 0

Rollback protection in Internal Trusted Storage

by Bojan Simoneta

Dear TF-M Community, I have a question regarding rollback protection in Internal Trusted Storage. Scenario: Recently we are seeing an increasing number of products which will come to market without internal Flash; together with this, there is also the requirement to store permanent keys using PSA key management APIs as psa_import_key, which will then in turn use Internal Trusted Storage as place where keys will be written. Considering these requirements there is a necessity to implement the Internal Trusted Storage in external Flash, which brings with it security challenges: the keys stored in external Flash would require confidentiality but also rollback protection. The encryption of ITS encryption was recently enabled as you can see in the following Pull request https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15096, but rollback protection is not yet implemented. Proposal: Our proposal would be to: - Add ITS rollback protection as optional feature, since it is not desired feature for product where the ITS storage is internal - Add rollback protection mechanism to Internal Trusted Storage functions relying on the NV counters APIs called from the platform layer, similar as is already done for Protected Storage Also, we are open to discuss any other proposal which would help us to fulfill the above requests (ITS in external Flash with still providing confidentiality and rollback protection). Thanks in advance for the answer and further guidance on the topic. KR, Bojan Simoneta Bojan Simoneta (He / Him / His) Principal Embedded SW Engineer Phone: +433124 299160 Email: bojan.simoneta(a)nxp.com<mailto:bojan.simoneta@nxp.com> [cid:image006.png@01DC347E.50852920] NXP Semiconductors Austria GmbH & Co KG | Mikronweg 1, 8101 Gratkorn | Austria | Sitz: Gratkorn, Österreich | Firmenbuchgericht: Landesgericht für ZRS Graz | Firmenbuchnummer: FN 541474 k | VAT: ATU76231908 Unless otherwise recorded in a signed, written agreement, all sales transactions by NXP are exclusively subject to NXP's Terms and Conditions of Commercial Sale ("NXP Terms") published at: www.nxp.com/profile/terms/index.html<http://www.nxp.com/profile/terms/index.html>. NXP explicitly rejects and disregards any terms and conditions of customer that add to, or differ from, NXP's Terms irrespective of when customer raises its terms. The information contained in this message is confidential. The message is intended solely for the addressee(s). If you are not the intended recipient, any use, dissemination, or reproduction is strictly prohibited and may be unlawful and you are asked to please contact the sender by return e-mail and destroy all copies of the original message.

5 months, 1 week

2
1
0 0

TF-M CI Coverity changes

by Matt Dalzell

Hi all, We are considering moving the TF-M Coverity scan (the results from https://ci.trustedfirmware.org/view/TF-M/job/tf-m-coverity/) to a private instance. I am sending this out to find out if anyone who is external to Arm uses these results, or would like to see the results in the future. If there is interest in keeping the public one working then we can have both the private and public ones running alongside each other to keep the results visible. Please let me know if you are a user of the current Coverity system, or wish to be able to view the results in the future so the jobs can be configured accordingly. If no interest is shown then the Coverity scan will be switched over to only the private instance. Thanks, Matt Dalzell - Arm

5 months, 1 week

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M