Hello all,
Today we have upgraded the version of Arm GNU Toolchain on the TF-M OpenCI to version 14.3rel1. We ask that you please update your local version to match this to allow for ongoing compatibility.
If you have any questions or issues, please do not hesitate to let me know.
Thanks,
Matt Dalzell - Arm
FYI
From: Saheer Babu via Tf-openci <tf-openci(a)lists.trustedfirmware.org>
Date: Wednesday, 10 September 2025 at 15:17
To: tf-openci(a)lists.trustedfirmware.org <tf-openci(a)lists.trustedfirmware.org>
Subject: [Tf-openci] CI infrastructure scheduled maintenance: 12th Sep 2025
Hi all,
We will be performing upgrade of the clusters hosting review.trustedfirmware.org and ci.trustedfirmware.org on Friday, 12th Sep 2025 at 16:00 GMT+1.
During this maintenance window, both services will be unavailable for approximately 4 hours.
A follow-up email will be sent once the services are fully restored.
Best regards,
Saheer
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.
--
Tf-openci mailing list -- tf-openci(a)lists.trustedfirmware.org
To unsubscribe send an email to tf-openci-leave(a)lists.trustedfirmware.org
Hello,
We've identified an issue with the TF-M versioning: it reports the wrong version from Git tags (showing v2.1.3 instead of the correct v2.2.1). As a temporary workaround, please set the version manually. We're working on a fix and will share updates as soon as possible.
Best regards,
Anton Komlev
Hello,
I’m trying to enable the secure debug feature and configured TF-M as
follows:
1) Configuration
# ./config/config_base.cmake
set(PLATFORM_PSA_ADAC_SECURE_DEBUG TRUE CACHE BOOL "Whether to use psa-adac
secure debug.")
set(PLATFORM_PSA_ADAC_SOURCE_PATH "DOWNLOAD" CACHE PATH "Path to source dir
of psa-adac.")
set(PLATFORM_PSA_ADAC_VERSION "819a254" CACHE STRING "The version of
psa-adac to use.")
2) Build result (error)
-- Populating libpsaadac
-- Configuring done (0.0s)
-- Generating done (0.0s)
-- Build files have been written to:
/home/jkpark/ADP620/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 ADAC: Check return value of
psa_adac_generate_challenge
[2/9] Performing update step for 'libpsaadac-populate'
e*rror: pathspec '819a254;;' did not match any file(s) known to git *
*CMake Error at .../libpsaadac-populate-gitupdate.cmake:188
(execute_process): *
* execute_process failed command indexes: *
* 1: "Child return code: 1" *
3) Generated ExternalProject invocation
/cmake_build/rdv3r1/0/lib/ext/libpsaadac-subbuild/CMakeLists.txt
include(ExternalProject)
ExternalProject_Add(libpsaadac-populate
"UPDATE_DISCONNECTED" "False"
"GIT_REPOSITORY" "https://git.trustedfirmware.org/shared/psa-adac.git"
"EXTERNALPROJECT_INTERNAL_ARGUMENT_SEPARATOR"
"GIT_TAG" "819a254" "" ""
SOURCE_DIR
"/home/jkpark/ADP620/tf-m/cmake_build/rdv3r1/0/lib/ext/libpsaadac-src"
BINARY_DIR
"/home/jkpark/ADP620/tf-m/cmake_build/rdv3r1/0/lib/ext/libpsaadac-build"
CONFIGURE_COMMAND ""
BUILD_COMMAND ""
INSTALL_COMMAND ""
TEST_COMMAND ""
USES_TERMINAL_DOWNLOAD YES
USES_TERMINAL_UPDATE YES
USES_TERMINAL_PATCH YES
)
*Questions *
*https://git.trustedfirmware.org/shared/psa-adac.git
<https://git.trustedfirmware.org/shared/psa-adac.git> *
*What is causing the tag-related error when using the repository at
https://git.trustedfirmware.org/shared/psa-adac.git
<https://git.trustedfirmware.org/shared/psa-adac.git> *
?
Environment
Path: /home/jkpark/ADP620/tf-m/cmake_build/rdv3r1/0/...
Platform: RDV3R1
I would be grateful for any advice or pointers from anyone familiar with
this.
Thank you!
Hi all,
TF-M has recently introduced Python packaging for its modules and
scripts. If you’re building the latest TF-M mainline, you’ll need to
install them by running the following command from the root of the TF-M
repository (using a virtual environment is recommended):
```
pip install .
```
or
```
# `-e` installs modules and scripts in editable/development mode i.e.
source edits are automatically reflected in your dev environment
pip install -e .
```
NOTE: You'll have to re-run the above command every time a new module is
added, module is renamed or a new dependency is added.
The documentation [1] has been updated with more details. In addition,
new guidelines are now available [2] for adding new scripts and modules.
Thank you.
Best regards,
Mudit Sharma
[1]:
https://trustedfirmware-m.readthedocs.io/en/latest/getting_started/index.ht…
[2]:
https://trustedfirmware-m.readthedocs.io/en/latest/contributing/python_scri…
Hi,
TF-M's tech forum of today is cancelled due to unforeseen circumstances. Talks that were scheduled for today are postponed. Will confirm in which one of the upcoming occurrences. Apologies for the short notice.
Thanks,
Antonio
________________________________
From: Trusted Firmware Public Meetings
Sent: Friday, June 6, 2025 10:03:13 AM
To: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com>; Anton Komlev <Anton.Komlev(a)arm.com>; Don Harbin <don.harbin(a)linaro.org>; abdelmalek.omar1(a)gmail.com <abdelmalek.omar1(a)gmail.com>; Kevin Townsend (kevin.townsend(a)linaro.org) <kevin.townsend(a)linaro.org>; seth(a)nxmlabs.com <seth(a)nxmlabs.com>; leonardo.sandoval(a)linaro.org <leonardo.sandoval(a)linaro.org>; Joanna Farley <Joanna.Farley(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Subject: TF-M Tech forum
When: Thursday, August 28, 2025 4:00 PM-5:00 PM.
Where: https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz…
This email keeps the event up to date in your calendar.
Set up inbox filters to hide this and similar calendar sync emails.
Learn more about calendar sync emails and setting up filters<https://support.google.com/calendar?p=filter_invitations>
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/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…>
===Zoom Info====
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Topic: TF-M Tech forum - US Time Zone Friendly
Time: Oct 29, 2020 03:00 PM Greenwich Mean Time
Every 4 weeks on Thu, until Mar 18, 2021, 6 occurrence(s)
Oct 29, 2020 03:00 PM
Nov 26, 2020 03:00 PM
Dec 24, 2020 03:00 PM
Jan 21, 2021 03:00 PM
Feb 18, 2021 03:00 PM
Mar 18, 2021 03:00 PM
Please download and import the following iCalendar (.ics) files to your calendar system.
Weekly: https://linaro-org.zoom.us/meeting/tJEocOmvpz4tHtYu0Wvn2fOsG91u0kv_ECPd/ics…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fmeeting%2Ft…>
Join Zoom Meeting
https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9557079…>
Meeting ID: 955 7079 5742
Passcode: 177658
One tap mobile
+12532158782,,95570795742# US (Tacoma)
+13462487799,,95570795742# 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)
877 853 5247 US Toll-free
888 788 0099 US Toll-free
Meeting ID: 955 7079 5742
Find your local number: https://linaro-org.zoom.us/u/abx3I7IoRq<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2Fabx3I7I…>
When
Every 4 weeks from 8am to 9am on Thursday (Mountain Standard Time - Phoenix)
Location
https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz…
View map<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9557079…>
Guests
Don Harbin<mailto:don.harbin@linaro.org> - creator
anton.komlev(a)arm.com<mailto:anton.komlev@arm.com>
abdelmalek.omar1(a)gmail.com<mailto:abdelmalek.omar1@gmail.com>
kevin.townsend(a)linaro.org<mailto:kevin.townsend@linaro.org>
seth(a)nxmlabs.com<mailto:seth@nxmlabs.com>
leonardo.sandoval(a)linaro.org<mailto:leonardo.sandoval@linaro.org>
Joanna Farley<mailto:joanna.farley@arm.com>
tf-m(a)lists.trustedfirmware.org<mailto:tf-m@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>
Dear TF-M Team,
I'm Takekazu Tabata, a director and architect from the Fujitsu processor team.
We are currently developing FUJITSU-MONAKA, which supports the CCA feature.
We have three questions regarding the TF-M documents and TF-M implementations.
We would greatly appreciate it if you could provide answers.
Question 1)
In the TF-M document “RSE provisioning”,
The CM provisioning Key is used to encrypt DM Provisioning Bundle.
https://trustedfirmware-m.readthedocs.io/en/latest/platform/arm/rse/rse_pro…
After the cold reset, the RSE will automatically transition to Device Manufacturer provisioning
state “DM” as the LCM hardware state-machine reads the values of the cm_config_1 and cm_config_2 fields as non-zero. This state is designed to provision the DM provisioning key, the DM code-encryption key and the DM config. The procedure follows the same steps as the CM provisioning flow, with the exception that the bundle will now be encrypted and signed using the CM provisioning key and must be placed at the base of VM1.
However, the purpose of the data provided in the DM is not described in this document. These data are not used in the source code of TF-M v2.2.0.
DM provisioning is probably assumed to be done during device manufacturing, but could you explain the purpose in more detail?
Also, What are the DM provisioning key, the DM code-encryption key and the DM config used for?
Question 2)
In the TF-M document “RSE integration guide”,
attestation key(CPAK) is derived by GUK.
https://trustedfirmware-m.readthedocs.io/en/latest/platform/arm/rse/rse_int…<https://trustedfirmware-m.readthedocs.io/en/latest/platform/arm/rse/rse_int…>
The GUK is a key unique to a group of chips that have identical security properties, used to derive the attestation key.
However, CPAK is derived from HUK in the source code of TF-M. GUK in the specification is a typo.
https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git…<https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git…>
/* This derives from HUK, there is a typo in the spec, not from GUK.
* FixMe: this should be configurable per platform
*/
return setup_key_from_derivation(KMU_HW_SLOT_HUK, NULL, iak_seed_label,
sizeof(iak_seed_label), NULL, 0,
RSE_KMU_SLOT_CPAK_SEED, /* FixMe: The slot needs rename to IAK_SEED */
&aes_key0_export_config, NULL, false,
boot_state_config);
Which is right, GUK or HUK?
If it‘s HUK (not Virtual HUK), is it no problem that multiple CPAKs are generated in Multi-socket systems?
Question 3)
In the CM/DM lifecycle state, is it no problem to create an original provisioning bundle to run chip or device verification programs in PE?
Thank you for your time and assistance.
Best regards,
TABATA
Dear TF-M Community,
I have a question regarding a specific use case involving interrupt handling
and domain preemption in a TrustZone-enabled system using TF-M.
In the scenario where the processor is executing within a Secure user
context (e.g., during Secure Partition execution), is it possible for an
interrupt assigned to the Non-Secure domain to pre-empt this Secure
execution?
* Does TF-M support such preemption by default?
* If not supported out-of-the-box, what modifications or configuration
changes would be required within TF-M to enable this behavior?
Any guidance on how TF-M manages interrupt priority and security attribution
in this context would be greatly appreciated.
Best regards,
Waqar Ali
Waqar Ali Tahir
(He / Him / His)
Embedded SW Engineer
Phone: +433124 299160
Email: <mailto:waqar.tahir@nxp.com> waqar.tahir(a)nxp.com
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 NXPs Terms and Conditions of
Commercial Sale (NXP Terms) published at:
<http://www.nxp.com/profile/terms/index.html>
www.nxp.com/profile/terms/index.html. NXP explicitly rejects and disregards
any terms and conditions of customer that add to, or differ from, NXPs
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.
Hi Raef,
I share the issue while applying shared patchset.
Because a variable 'dma_channel_amount' is used after the DMA wipe DTCM,
it causes that dma_channel_amount have wrong data when waiting for DMA channel finish.
/* Configure all DMA channels to wipe the DTCM with the random value in parallel. */
for (int idx = 0; idx < dma_channel_amount; idx++) {
/* DMA channel configuration to wipe DTCM*/
}
/* Wait for all the DMA channels to finish */
for (int idx = 0; idx < dma_channel_amount; idx++) { // Error occurs at here
while ((*((volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x000)) & 0x1) != 0) {}
}
So i have chosen a way that use defined value using #define like below.
/* Enable the TRAM */
*(volatile uint32_t *)(TRAM_BASE_S + 0x004) = 0x00000001;
/* Generate the TRAM erase random value */
tram_erase_value = *((volatile uint32_t *)(CC3XX_BASE_S + 0x124));
/* Configure all DMA channels to wipe the DTCM with the random value in parallel. */
for (int idx = 0; idx < DMA350_DMA0_CHANNEL_COUNT; idx++) {
/* LINKADDR must be cleared because the command linking is used in DMA H/W boot. */
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x078) = 0x00000000;
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x038) = tram_erase_value;
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x02c) = 0x000F0044;
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x018) =
DTCM_CPU0_BASE_S + (DTCM_SIZE / DMA350_DMA0_CHANNEL_COUNT * idx);
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x030) = 0x00010000;
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x020) =
(DTCM_SIZE / sizeof(uint64_t) / DMA350_DMA0_CHANNEL_COUNT) << 16;
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x024) = 0x00000000;
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x00c) = 0x01200603;
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x008) = 0x00000000;
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x000) = 0x00000001;
}
/* Wait for all the DMA channels to finish */
for (int idx = 0; idx < DMA350_DMA0_CHANNEL_COUNT; idx++) {
while ((*((volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x000)) & 0x1) != 0) {}
}
Please refer to it.
Best Regards
RH Kim
----- 원본 메시지 -----
보낸 사람: Raef Coles <Raef.Coles(a)arm.com>
받는 사람: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.xn--org>,-7104au55ev23e <winxp4333(a)adtek.co.kr>
날짜: 2025-07-28 22:06:49
제목: Re: [TF-M] Re: RSE booting with HardFault issue when TRAM enabled
Ah thanks for the testing - I had indeed reused a variable after the TRAM init but before the zero. The following patchset should fix it, and remove the unneeded DMA ICS commands
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/41222/2https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/41224/1
Thanks,
Raef
________________________________________
From: 김륜현 via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 28 July 2025 12:57
To: Raef Coles; tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Re: RSE booting with HardFault issue when TRAM enabled
OK, Thank you for sharing the plan.
About applying patch you gave,(https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40838)
Using variables immediately after TRAM enable can cause bus errors due to the same reason we discussing.
/* Enable the TRAM */
*(volatile uint32_t *)(TRAM_BASE_S + 0x004) = 0x00000001;
In actual, the access to variables in DTCM occur bus error after TRAM enabled.
So i modified that it temporarily clear to 0 without using variable.
/* Enable the TRAM */
*(volatile uint32_t *)(TRAM_BASE_S + 0x004) = 0x00000001;
/* Erase the DTCM */
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x038) = 0; // FILLVAL
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x02c) = 0x000F0044; // DESTRANSCFG
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x018) = DTCM_CPU0_BASE_S; // DESADDR
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x030) = 0x00010000; // XADDRINC
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x020) = (DTCM_SIZE / sizeof(uint64_t)) << 16; // XSIZE
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x00c) = 0x1200603; // CONFIG
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x008) = 0x00000000; // Disable All Interrupt
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x000) = 0x00000001; // RUN_CMD
while ((*((volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x000)) & 0x1) != 0) {}
But, it needs to find a fundamental solution.
Please check it and i will share the solution if we find good idea.
Best Regards
RH Kim
----- 원본 메시지 -----
보낸 사람: Raef Coles <Raef.Coles(a)arm.com>
받는 사람: 김륜현 <winxp4333@adtek.co.kr>,tf-m@lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
날짜: 2025-07-28 19:28:00
제목: Re: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled
Yeah you're right, the patch does add some duplication. In future we plan to remove the commands to generate the TRAM key, set the TRAM key, initialize the TRAM and erase the TRAM from the DMA ICS. This way it will always be handled in SW.
The issue we have is that the TRAM setup requires retrieving random values from the TRNG, and whether that is possible in the DMA ICS depends on which HW TRNG is being used. With a single register read interface (which is what the ICS assumes) it works okay, but with (for example) the cryptocell TRNG it's not possible to read using the ICS since it requires a poll on a status register and it's not possible to encode that into a DMA command.
To avoid having some TRNGs using the ICS and some using SW, we figured it was more sensible to perform the TRAM setup in SW in all cases.
I believe that the new SW flow _should_ work if the DMA flow has already been run, but if there are any issues (likely with the KMU keyslot) then the simplest solution is to just remove the DMA commands.
Raef
________________________________________
From: 김륜현 <winxp4333(a)adtek.co.kr>
Sent: 28 July 2025 02:00
To: Raef Coles; tf-m(a)lists.trustedfirmware.org
Subject: Re: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled
Hi Raef
Thanks for your answer.
I'm trying to apply your patch our base code, but some of issue occur.
I will share the result when the patch is applied properly.
Before that, i have a question.
As i know, DMA descriptor(Program6) enables TRAM on DMA H/W boot.
(platform/ext/target/arm/rse/common/bl1/scripts)
I think that it seems to do duplicate operation as S/W about enabling TRAM.
Regarding this, is there still no fixed method for enabling TRAM?
Best Regards
RH Kim
----- 원본 메시지 -----
보낸 사람: Raef Coles <Raef.Coles(a)arm.com>
받는 사람: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.xn--org>,-7104au55ev23e <winxp4333(a)adtek.co.kr>
날짜: 2025-07-24 21:00:22
제목: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled
Hey RH
Apologies, this has been a known issue for a while (or rather, a series of known issues that we keep fixing).
We've just merged a patch upstream which:
* Replaces the function calls with fixed register writes to avoid issues with uninitialized global data
* Performs DTCM initialization in all cases, avoiding relying on the DMA ICS or having to check the SP mode
You can find it here https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40838
Unfortunately we've only been able to test it on the FVP at the moment, which has limited ECC support. If you'd be able to test the patch and let me know if it fixes your issue, that would be appreciated.
Raef
________________________________________
From: 김륜현 via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 24 July 2025 05:38
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] RSE booting with HardFault issue when TRAM enabled
Dear TF-M developers
Hello, i'm developing and porting TF-M our platforms based on RDV3R1.
To enable TRAM, i modified a cmake config file like below(platform/ext/target/arm/rse/common/config.cmake)
- set(RSE_ENABLE_TRAM OFF CACHE BOOL "Whether TRAM encryption is enabled")
+ set(RSE_ENABLE_TRAM ON CACHE BOOL "Whether TRAM encryption is enabled")
First of all, RSE core boots with Virgin CM
In this mode, Secure Provisioning is not enabled so that the DTCM don't be initialized even if TRAM is enabled.
setup_tram_encryption()(a)startup_rse_bl1_1.c
tram_enable_encryption(&tram_dev_s);
if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) {
bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word));
for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) {
((uint32_t *)DTCM_BASE_S)[idx] = random_word;
}
}
Because DTCM doesn't be initialized, the next codes which use global variable in BL1_1 data section on DTCM cause hardfault.
So, i applied the workaround by modifying condition like below.
tram_enable_encryption(&tram_dev_s);
- if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) {
+ if ((lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) {
bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word));
for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) {
((uint32_t *)DTCM_BASE_S)[idx] = random_word;
}
}
But the global variable in uninitialized DTCM are also used in bl1_trng_generate_random().
So, i tried to initialize DTCM as 0 without calling bl1_trng_generate_random().
But after that, setting SP_ENABLED for CM Provisioning causes warm reset, TRAM is disabled but DTCM doesn't be initialized.
It causes same problem.
I know that enabling TRAM is performed DMA descriptor without RSE_ENABLE_TRAM option, it may also cause the problem because of the phenomenon that TRAM is disabled but DTCM doesn't be initialized when warm reset.
Should i modify let it use local variable? or is there anything to fix this problem?
Best Regards
RH Kim
OK, Thank you for sharing the plan.
About applying patch you gave,(https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40838)…
Using variables immediately after TRAM enable can cause bus errors due to the same reason we discussing.
/* Enable the TRAM */
*(volatile uint32_t *)(TRAM_BASE_S + 0x004) = 0x00000001;
In actual, the access to variables in DTCM occur bus error after TRAM enabled.
So i modified that it temporarily clear to 0 without using variable.
/* Enable the TRAM */
*(volatile uint32_t *)(TRAM_BASE_S + 0x004) = 0x00000001;
/* Erase the DTCM */
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x038) = 0; // FILLVAL
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x02c) = 0x000F0044; // DESTRANSCFG
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x018) = DTCM_CPU0_BASE_S; // DESADDR
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x030) = 0x00010000; // XADDRINC
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x020) = (DTCM_SIZE / sizeof(uint64_t)) << 16; // XSIZE
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x00c) = 0x1200603; // CONFIG
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x008) = 0x00000000; // Disable All Interrupt
*(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x000) = 0x00000001; // RUN_CMD
while ((*((volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x000)) & 0x1) != 0) {}
But, it needs to find a fundamental solution.
Please check it and i will share the solution if we find good idea.
Best Regards
RH Kim
----- 원본 메시지 -----
보낸 사람: Raef Coles <Raef.Coles(a)arm.com>
받는 사람: 김륜현 <winxp4333@adtek.co.kr>,tf-m@lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
날짜: 2025-07-28 19:28:00
제목: Re: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled
Yeah you're right, the patch does add some duplication. In future we plan to remove the commands to generate the TRAM key, set the TRAM key, initialize the TRAM and erase the TRAM from the DMA ICS. This way it will always be handled in SW.
The issue we have is that the TRAM setup requires retrieving random values from the TRNG, and whether that is possible in the DMA ICS depends on which HW TRNG is being used. With a single register read interface (which is what the ICS assumes) it works okay, but with (for example) the cryptocell TRNG it's not possible to read using the ICS since it requires a poll on a status register and it's not possible to encode that into a DMA command.
To avoid having some TRNGs using the ICS and some using SW, we figured it was more sensible to perform the TRAM setup in SW in all cases.
I believe that the new SW flow _should_ work if the DMA flow has already been run, but if there are any issues (likely with the KMU keyslot) then the simplest solution is to just remove the DMA commands.
Raef
________________________________________
From: 김륜현 <winxp4333(a)adtek.co.kr>
Sent: 28 July 2025 02:00
To: Raef Coles; tf-m(a)lists.trustedfirmware.org
Subject: Re: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled
Hi Raef
Thanks for your answer.
I'm trying to apply your patch our base code, but some of issue occur.
I will share the result when the patch is applied properly.
Before that, i have a question.
As i know, DMA descriptor(Program6) enables TRAM on DMA H/W boot.
(platform/ext/target/arm/rse/common/bl1/scripts)
I think that it seems to do duplicate operation as S/W about enabling TRAM.
Regarding this, is there still no fixed method for enabling TRAM?
Best Regards
RH Kim
----- 원본 메시지 -----
보낸 사람: Raef Coles <Raef.Coles(a)arm.com>
받는 사람: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.xn--org>,-7104au55ev23e <winxp4333(a)adtek.co.kr>
날짜: 2025-07-24 21:00:22
제목: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled
Hey RH
Apologies, this has been a known issue for a while (or rather, a series of known issues that we keep fixing).
We've just merged a patch upstream which:
* Replaces the function calls with fixed register writes to avoid issues with uninitialized global data
* Performs DTCM initialization in all cases, avoiding relying on the DMA ICS or having to check the SP mode
You can find it here https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40838
Unfortunately we've only been able to test it on the FVP at the moment, which has limited ECC support. If you'd be able to test the patch and let me know if it fixes your issue, that would be appreciated.
Raef
________________________________________
From: 김륜현 via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 24 July 2025 05:38
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] RSE booting with HardFault issue when TRAM enabled
Dear TF-M developers
Hello, i'm developing and porting TF-M our platforms based on RDV3R1.
To enable TRAM, i modified a cmake config file like below(platform/ext/target/arm/rse/common/config.cmake)
- set(RSE_ENABLE_TRAM OFF CACHE BOOL "Whether TRAM encryption is enabled")
+ set(RSE_ENABLE_TRAM ON CACHE BOOL "Whether TRAM encryption is enabled")
First of all, RSE core boots with Virgin CM
In this mode, Secure Provisioning is not enabled so that the DTCM don't be initialized even if TRAM is enabled.
setup_tram_encryption()(a)startup_rse_bl1_1.c
tram_enable_encryption(&tram_dev_s);
if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) {
bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word));
for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) {
((uint32_t *)DTCM_BASE_S)[idx] = random_word;
}
}
Because DTCM doesn't be initialized, the next codes which use global variable in BL1_1 data section on DTCM cause hardfault.
So, i applied the workaround by modifying condition like below.
tram_enable_encryption(&tram_dev_s);
- if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) {
+ if ((lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) {
bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word));
for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) {
((uint32_t *)DTCM_BASE_S)[idx] = random_word;
}
}
But the global variable in uninitialized DTCM are also used in bl1_trng_generate_random().
So, i tried to initialize DTCM as 0 without calling bl1_trng_generate_random().
But after that, setting SP_ENABLED for CM Provisioning causes warm reset, TRAM is disabled but DTCM doesn't be initialized.
It causes same problem.
I know that enabling TRAM is performed DMA descriptor without RSE_ENABLE_TRAM option, it may also cause the problem because of the phenomenon that TRAM is disabled but DTCM doesn't be initialized when warm reset.
Should i modify let it use local variable? or is there anything to fix this problem?
Best Regards
RH Kim
Yeah you're right, the patch does add some duplication. In future we plan to remove the commands to generate the TRAM key, set the TRAM key, initialize the TRAM and erase the TRAM from the DMA ICS. This way it will always be handled in SW.
The issue we have is that the TRAM setup requires retrieving random values from the TRNG, and whether that is possible in the DMA ICS depends on which HW TRNG is being used. With a single register read interface (which is what the ICS assumes) it works okay, but with (for example) the cryptocell TRNG it's not possible to read using the ICS since it requires a poll on a status register and it's not possible to encode that into a DMA command.
To avoid having some TRNGs using the ICS and some using SW, we figured it was more sensible to perform the TRAM setup in SW in all cases.
I believe that the new SW flow _should_ work if the DMA flow has already been run, but if there are any issues (likely with the KMU keyslot) then the simplest solution is to just remove the DMA commands.
Raef
________________________________________
From: 김륜현 <winxp4333(a)adtek.co.kr>
Sent: 28 July 2025 02:00
To: Raef Coles; tf-m(a)lists.trustedfirmware.org
Subject: Re: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled
Hi Raef
Thanks for your answer.
I'm trying to apply your patch our base code, but some of issue occur.
I will share the result when the patch is applied properly.
Before that, i have a question.
As i know, DMA descriptor(Program6) enables TRAM on DMA H/W boot.
(platform/ext/target/arm/rse/common/bl1/scripts)
I think that it seems to do duplicate operation as S/W about enabling TRAM.
Regarding this, is there still no fixed method for enabling TRAM?
Best Regards
RH Kim
----- 원본 메시지 -----
보낸 사람: Raef Coles <Raef.Coles(a)arm.com>
받는 사람: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>,김륜현 <winxp4333(a)adtek.co.kr>
날짜: 2025-07-24 21:00:22
제목: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled
Hey RH
Apologies, this has been a known issue for a while (or rather, a series of known issues that we keep fixing).
We've just merged a patch upstream which:
* Replaces the function calls with fixed register writes to avoid issues with uninitialized global data
* Performs DTCM initialization in all cases, avoiding relying on the DMA ICS or having to check the SP mode
You can find it here https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40838
Unfortunately we've only been able to test it on the FVP at the moment, which has limited ECC support. If you'd be able to test the patch and let me know if it fixes your issue, that would be appreciated.
Raef
________________________________________
From: 김륜현 via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 24 July 2025 05:38
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] RSE booting with HardFault issue when TRAM enabled
Dear TF-M developers
Hello, i'm developing and porting TF-M our platforms based on RDV3R1.
To enable TRAM, i modified a cmake config file like below(platform/ext/target/arm/rse/common/config.cmake)
- set(RSE_ENABLE_TRAM OFF CACHE BOOL "Whether TRAM encryption is enabled")
+ set(RSE_ENABLE_TRAM ON CACHE BOOL "Whether TRAM encryption is enabled")
First of all, RSE core boots with Virgin CM
In this mode, Secure Provisioning is not enabled so that the DTCM don't be initialized even if TRAM is enabled.
setup_tram_encryption()(a)startup_rse_bl1_1.c
tram_enable_encryption(&tram_dev_s);
if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) {
bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word));
for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) {
((uint32_t *)DTCM_BASE_S)[idx] = random_word;
}
}
Because DTCM doesn't be initialized, the next codes which use global variable in BL1_1 data section on DTCM cause hardfault.
So, i applied the workaround by modifying condition like below.
tram_enable_encryption(&tram_dev_s);
- if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) {
+ if ((lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) {
bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word));
for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) {
((uint32_t *)DTCM_BASE_S)[idx] = random_word;
}
}
But the global variable in uninitialized DTCM are also used in bl1_trng_generate_random().
So, i tried to initialize DTCM as 0 without calling bl1_trng_generate_random().
But after that, setting SP_ENABLED for CM Provisioning causes warm reset, TRAM is disabled but DTCM doesn't be initialized.
It causes same problem.
I know that enabling TRAM is performed DMA descriptor without RSE_ENABLE_TRAM option, it may also cause the problem because of the phenomenon that TRAM is disabled but DTCM doesn't be initialized when warm reset.
Should i modify let it use local variable? or is there anything to fix this problem?
Best Regards
RH Kim
Hi Raef
Thanks for your answer.
I'm trying to apply your patch our base code, but some of issue occur.
I will share the result when the patch is applied properly.
Before that, i have a question.
As i know, DMA descriptor(Program6) enables TRAM on DMA H/W boot.
(platform/ext/target/arm/rse/common/bl1/scripts)
I think that it seems to do duplicate operation as S/W about enabling TRAM.
Regarding this, is there still no fixed method for enabling TRAM?
Best Regards
RH Kim
----- 원본 메시지 -----
보낸 사람: Raef Coles <Raef.Coles(a)arm.com>
받는 사람: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.xn--org>,-7104au55ev23e <winxp4333(a)adtek.co.kr>
날짜: 2025-07-24 21:00:22
제목: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled
Hey RH
Apologies, this has been a known issue for a while (or rather, a series of known issues that we keep fixing).
We've just merged a patch upstream which:
* Replaces the function calls with fixed register writes to avoid issues with uninitialized global data
* Performs DTCM initialization in all cases, avoiding relying on the DMA ICS or having to check the SP mode
You can find it here https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40838
Unfortunately we've only been able to test it on the FVP at the moment, which has limited ECC support. If you'd be able to test the patch and let me know if it fixes your issue, that would be appreciated.
Raef
________________________________________
From: 김륜현 via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 24 July 2025 05:38
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] RSE booting with HardFault issue when TRAM enabled
Dear TF-M developers
Hello, i'm developing and porting TF-M our platforms based on RDV3R1.
To enable TRAM, i modified a cmake config file like below(platform/ext/target/arm/rse/common/config.cmake)
- set(RSE_ENABLE_TRAM OFF CACHE BOOL "Whether TRAM encryption is enabled")
+ set(RSE_ENABLE_TRAM ON CACHE BOOL "Whether TRAM encryption is enabled")
First of all, RSE core boots with Virgin CM
In this mode, Secure Provisioning is not enabled so that the DTCM don't be initialized even if TRAM is enabled.
setup_tram_encryption()(a)startup_rse_bl1_1.c
tram_enable_encryption(&tram_dev_s);
if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) {
bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word));
for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) {
((uint32_t *)DTCM_BASE_S)[idx] = random_word;
}
}
Because DTCM doesn't be initialized, the next codes which use global variable in BL1_1 data section on DTCM cause hardfault.
So, i applied the workaround by modifying condition like below.
tram_enable_encryption(&tram_dev_s);
- if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) {
+ if ((lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) {
bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word));
for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) {
((uint32_t *)DTCM_BASE_S)[idx] = random_word;
}
}
But the global variable in uninitialized DTCM are also used in bl1_trng_generate_random().
So, i tried to initialize DTCM as 0 without calling bl1_trng_generate_random().
But after that, setting SP_ENABLED for CM Provisioning causes warm reset, TRAM is disabled but DTCM doesn't be initialized.
It causes same problem.
I know that enabling TRAM is performed DMA descriptor without RSE_ENABLE_TRAM option, it may also cause the problem because of the phenomenon that TRAM is disabled but DTCM doesn't be initialized when warm reset.
Should i modify let it use local variable? or is there anything to fix this problem?
Best Regards
RH Kim
Dear TF-M developers
Hello, i'm developing and porting TF-M our platforms based on RDV3R1.
To enable TRAM, i modified a cmake config file like below(platform/ext/target/arm/rse/common/config.cmake)
- set(RSE_ENABLE_TRAM OFF CACHE BOOL "Whether TRAM encryption is enabled")
+ set(RSE_ENABLE_TRAM ON CACHE BOOL "Whether TRAM encryption is enabled")
First of all, RSE core boots with Virgin CM
In this mode, Secure Provisioning is not enabled so that the DTCM don't be initialized even if TRAM is enabled.
setup_tram_encryption()(a)startup_rse_bl1_1.c
tram_enable_encryption(&tram_dev_s);
if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) {
bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word));
for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) {
((uint32_t *)DTCM_BASE_S)[idx] = random_word;
}
}
Because DTCM doesn't be initialized, the next codes which use global variable in BL1_1 data section on DTCM cause hardfault.
So, i applied the workaround by modifying condition like below.
tram_enable_encryption(&tram_dev_s);
- if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) {
+ if ((lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) {
bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word));
for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) {
((uint32_t *)DTCM_BASE_S)[idx] = random_word;
}
}
But the global variable in uninitialized DTCM are also used in bl1_trng_generate_random().
So, i tried to initialize DTCM as 0 without calling bl1_trng_generate_random().
But after that, setting SP_ENABLED for CM Provisioning causes warm reset, TRAM is disabled but DTCM doesn't be initialized.
It causes same problem.
I know that enabling TRAM is performed DMA descriptor without RSE_ENABLE_TRAM option, it may also cause the problem because of the phenomenon that TRAM is disabled but DTCM doesn't be initialized when warm reset.
Should i modify let it use local variable? or is there anything to fix this problem?
Best Regards
RH Kim
Hello,
This is a notification regarding a newly reported security vulnerability in Trusted Firmware-M (TF-M):
TFMV-9: Fix unchecked TLV payload length by Bartek Piekarski from Product Security team, Arm Ltd.
Please find the detailed security advisory attached. The fix for this issue has been merged into the latest main branch under the same identifier:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40872
We are currently preparing hotfix releases v2.1.3 and v2.2.1, which will include this fix along with other bug fixes reported up to the release date via the TF-M issue tracker:
https://github.com/TrustedFirmware-M/trusted-firmware-m/issues?q=is%3Aissue
Thanks, and best regards
Anton Komlev
Hello,
I am currently developing TF-M on the RDV3R1 S/W platform, and I would like
to report a potential issue observed during runtime with the
integrity_checker_compute_value() function in BL2.
Problem Description:
Inside the integrity_checker_compute_value() function, the iccva register
is set to the address of either the value or temp_val variable, as shown in
the example below.
enum integrity_checker_error_t integrity_checker_compute_value(struct
integrity_checker_dev_t *dev,
enum
integrity_checker_mode_t mode,
const
uint32_t *data, size_t size,
uint32_t
*value, size_t value_size,
size_t
*value_len)
{
volatile uint32_t __ALIGNED(INTEGRITY_CHECKER_REQUIRED_ALIGNMENT)
temp_val[INTEGRITY_CHECKER_OUTPUT_SIZE_SHA256 / sizeof(uint32_t)] =
{0};
volatile uint32_t *value_ptr = value;
struct _integrity_checker_reg_map_t* p_integrity_checker =
(struct _integrity_checker_reg_map_t*)dev->cfg->base;
enum integrity_checker_error_t err;
uint32_t iccval = 0;
err = check_mode_is_supported(dev, mode, true);
if (err != INTEGRITY_CHECKER_ERROR_NONE) {
return err;
}
if (value_size < mode_sizes[mode]) {
FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_BUFFER_TOO_SMALL);
return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_BUFFER_TOO_SMALL;
}
if (((uintptr_t)data % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) {
FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_ALIGNMENT);
return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_ALIGNMENT;
}
if ((size % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) {
FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_LENGTH);
return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_LENGTH;
}
if (((uintptr_t)value % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) {
value_ptr = temp_val;
}
init_integrity_checker(dev, &iccval);
/* Set algorithm */
iccval |= (mode & 0b111) << 1;
/* Set to compute mode */
iccval |= 1 << 4;
/* Configure input data. Size is in words */
p_integrity_checker->icda = remap_addr(dev, (uintptr_t)data);
p_integrity_checker->icdl = size / INTEGRITY_CHECKER_REQUIRED_ALIGNMENT;
/* Set output address */
p_integrity_checker->iccva = remap_addr(dev, (uintptr_t)value_ptr);
/* Start integrity checker */
iccval |= 1;
p_integrity_checker->icc = iccval;
/* Poll for any interrupts */
while(!p_integrity_checker->icis) {}
/* Check for any unusual error interrupts */
if (p_integrity_checker->icis & (~0b11)) {
FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_OPERATION_FAILED);
return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_OPERATION_FAILED;
}
if (value_ptr != value) {
for (int idx = 0; idx < mode_sizes[mode] / sizeof(uint32_t); idx++)
{
value[idx] = value_ptr[idx];
}
}
if (value_len != NULL) {
*value_len = mode_sizes[mode];
}
return INTEGRITY_CHECKER_ERROR_NONE;
}
static void init_integrity_checker(struct integrity_checker_dev_t *dev,
uint32_t *iccval)
{
struct _integrity_checker_reg_map_t* p_integrity_checker =
(struct _integrity_checker_reg_map_t*)dev->cfg->base;
/* Set MatchTriggerDisable, as it is mandatory. */
*iccval |= 1 << 5;
/* Set EncompvalOut so the integrity checker writes the value pointer in
* compute mode.
*/
*iccval |= 1 << 6;
*iccval |= (IC_APROT_SECURE_PRIVILEGED & 0b11) << 7;
*iccval |= (IC_APROT_SECURE_PRIVILEGED & 0b11) << 9;
/* Disable all alarms */
p_integrity_checker->icae = 0;
/* Enable and clear all interrupts */
p_integrity_checker->icie = 0xFF;
p_integrity_checker->icic = 0xFF;
}
The issue arises because the memory areas pointed to by value and temp_val
are cacheable (e.g., located in the vm0 memory region, which is configured
as cacheable).
As a result, even though the integrity checker writes the output data to
the physical address of value or temp_val, the CPU cache is not updated,
and this leads to stale data being read later in software, resulting in
runtime errors.
Expected Behavior:
Ideally, the memory region used for integrity checker output should either
be:
Non-cacheable, or
Explicitly synchronized (e.g., cache invalidated or cleaned) after the
integrity checker operation.
Could you please confirm whether this is a known issue, and advise on the
recommended way to handle integrity checker outputs with respect to cache
settings?
Thank you.
JK Park
Hello, I'm a RSE firmware developer for Arm Neoverse V3 core.
I tried to build with argument MCUBOOT_ENC_IMAGES, MCUBOOT_ENCRYPT_RSA, and MCUBOOT_USE_PSA_CRYPTO for RSE PE encryption.
In this process, I encountered an error during build TF-M using the repo for tag:RD-INFRA-2025.07.03.
It seems that linking problem, and I found out that the error occurred while configuring BL2.
However, that's all. Can anyone help me?
Below log is in my terminal output.
p.s. If I reached wrong site, please forgive me and teach me a right one.
cmake --build build --target bl2
[ 0%] Built target manifest_tool
[ 0%] Built target bl2_scatter
[ 10%] Built target bl2_cc3xx_psa_driver_api
[ 31%] Built target bl2_cc3xx
[ 68%] Built target platform_bl2
[ 78%] Built target bl2_crypto
[ 94%] Built target bootutil
[ 94%] Linking C executable ../bin/bl2.axf
/home/gth1919/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: ext/mcuboot/bootutil/libbootutil.a(encrypted.o): in function `bootutil_rsa_oaep_decrypt':
/TF_M/build/lib/ext/mcuboot-src/boot/bootutil/include/bootutil/crypto/rsa.h:107: undefined reference to `psa_asymmetric_decrypt'
Memory region Used Size Region Size %age Used
FLASH: 80356 B 126 KB 62.28%
RAM: 35360 B 896 KB 3.85%
collect2: error: ld returned 1 exit status
gmake[3]: *** [bl2/CMakeFiles/bl2.dir/build.make:222: bin/bl2.axf] Error 1
gmake[2]: *** [CMakeFiles/Makefile2:2661: bl2/CMakeFiles/bl2.dir/all] Error 2
gmake[1]: *** [CMakeFiles/Makefile2:2668: bl2/CMakeFiles/bl2.dir/rule] Error 2
gmake: *** [Makefile:520: bl2] Error 2
HP.
Mail.
010-6768-7791
gth1919(a)adtek.co.kr
Application Platform Group김태훈 연구원
(주)에이디테크놀로지
(16512) 경기도 수원시 영통구 광교중앙로248번길 7-8
Web. http://www.adtek.co.kr
Hi everyone,
We would like to propose the deprecation of the following two TF-M platforms:
1. Musca-S1 (Arm)
Musca-S1 was one of the earliest platforms featuring an Armv8-M silicon implementation, providing a valuable real hardware target for initial development. However, with the availability of many modern hardware platforms, Musca-S1 is no longer essential and can be deprecated.
2. BL5340_dvk_cpuapp (Laird Connectivity)
This platform was initially proposed for deprecation at the end of 2023. Support activity has been minimal, and it closely mirrors the already-supported nRF5340 platform from Nordic Semiconductor.
Please share any comments or objections regarding this proposal. If no major concerns are raised by the end of June 2025, we plan to mark these platforms as deprecated and proceed with their removal from the codebase.
Thank you,
Anton
Hi All,
We have recently undergone a migration of our Gerrit server and are seeing some issues.
One such change appears to be that https://review.trustedfirmware.org/TF-M/trusted-firmware-m no longer resolves to https://review.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m. So please use the latter link if that is what you wish to access.
This is causing a large slow-down on the CI causing jobs to not be run.
These issues are being actively worked on and we hope all will be back up and running normally soon.
If you have any questions or related issues please feel free to respond to this chain.
Thank you for your patience,
Matt
Hi
When compiling with IAR bxarm 9.7.1 i get the following linker errors:
cmake -S . -B cmake_build -DTFM_PLATFORM=arm/mps2/an521 -DTFM_TOOLCHAIN_FILE=toolchain_IARARM.cmake
cmake --build cmake_build -- install
[25/31] Linking C executable bin/tfm_s.axf
Warning[Li065]: duplicate file: "/home/ubuntu/import/source/trusted-firmware-m/
cmake_build/platform/libplatform_s.a"
Warning[Li065]: duplicate file: "/home/ubuntu/import/source/trusted-firmware-m/
cmake_build/secure_fw/partitions/lib/runtime/libtfm_sprt.a"
Warning[Li065]: duplicate file: "/home/ubuntu/import/source/trusted-firmware-m/
cmake_build/secure_fw/spm/libtfm_spm.a"
In the build.ninja file you can see that all those libraries are includes twice.
LINK_LIBRARIES = platform/libplatform_s.a secure_fw/partitions/lib/runtime/libtfm_sprt.a secure_fw/spm/libtfm_spm.a secure_fw/partitions/internal_trusted_storage/libtfm_psa_rot_partition_its.a secure_fw/partitions/platform/libtfm_psa_rot_partition_platform.a platform/libplatform_s.a secure_fw/partitions/lib/runtime/libtfm_sprt.a secure_fw/spm/libtfm_spm.a secure_fw/partitions/internal_trusted_storage/libtfm_psa_rot_partition_its.a secure_fw/partitions/platform/libtfm_psa_rot_partition_platform.a
Is there a reason this is not resolved or this just the way Cmake works?
Is there an easy way to resolve this on the platform level?
I used the an521 as a template to create my platform.
In my platform this list grows with every feature I activate:
Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil
d/platform/libplatform_s.a"
Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil
d/secure_fw/partitions/lib/runtime/libtfm_sprt.a"
Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil
d/secure_fw/spm/libtfm_spm.a"
Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil
d/platform/libplatform_crypto_keys.a"
Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil
d/secure_fw/partitions/crypto/mbedcrypto/library/libmbedcrypto.a"
Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil
d/secure_fw/partitions/crypto/libtfm_psa_rot_partition_crypto.a"
Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil
d/secure_fw/partitions/internal_trusted_storage/libtfm_psa_rot_partit
ion_its.a"
Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil
d/secure_fw/partitions/platform/libtfm_psa_rot_partition_platform.a"
Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil
d/secure_fw/partitions/firmware_update/libtfm_psa_rot_partition_fwu.a
"
Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil
d/secure_fw/partitions/lib/runtime/libtfm_sp_log.a"
Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil
d/platform/libplatform_s.a"
Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil
d/secure_fw/partitions/lib/runtime/libtfm_sprt.a"
Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil
d/secure_fw/spm/libtfm_spm.a"
Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil
d/platform/libplatform_crypto_keys.a"
Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil
d/secure_fw/partitions/crypto/mbedcrypto/library/libmbedcrypto.a"
Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil
d/secure_fw/partitions/crypto/libtfm_psa_rot_partition_crypto.a"
Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil
d/secure_fw/partitions/internal_trusted_storage/libtfm_psa_rot_partit
ion_its.a"
Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil
d/secure_fw/partitions/platform/libtfm_psa_rot_partition_platform.a"
Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil
d/secure_fw/partitions/firmware_update/libtfm_psa_rot_partition_fwu.a
"
Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil
d/secure_fw/partitions/lib/runtime/libtfm_sp_log.a"
If possible, I want to build without warnings.
Thanks for your help
Kind regards,
Nico
Hello,
I just recently found out that there's a concept of key ownership in TF-M
(e.g., if a new secure partition creates a key and returns the key handle
to NSPE, NSPE can't export it even if the key is config-ed to be exportable
-- the key can only be used by the owner).
My question is: is this design based on PSA or specific to just TF-M
implementation?
Thank you in advance,
--
Oak Norrathep
--
ศูนย์กลางการศึกษานานาชาติ มุ่งสู่ความเป็นเลิศทางวิชาการของอาเซียน
International education hub towards ASEAN’s academic excellence
Hi TF-M community,
When I am trying to build TF-M regression test for 2.2.x release, I sets the tf-m-tests repo version to recommended TF-Mv2.1.2-RC2. The tf-m-tests tests_reg/spe/CMakeLists.txt has following line:
install(FILES ${CONFIG_TFM_SOURCE_PATH}/lib/ext/qcbor/q_useful_buf.h
DESTINATION ${CMAKE_BINARY_DIR}/api_ns/qcbor/inc)
However, release 2.2.x https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git… has removed q_useful_buf.h. Therefore, causing a build error.
Is there anything I am missing. Any help would be appreciated.
Best regards,
Hao
Dear whoever that may concern,
I am trying to build TF-M with release/2.1.x. The first error I see when cloning mbedcrypto is
Cloning into 'mbedcrypto-src'...
remote: Enumerating objects: 31188, done.
remote: Counting objects: 100% (31188/31188), done.
remote: Compressing objects: 100% (15898/15898), done.
remote: Total 31188 (delta 24658), reused 20224 (delta 15043), pack-reused 0 (from 0)
Receiving objects: 100% (31188/31188), 35.81 MiB | 4.89 MiB/s, done.
Resolving deltas: 100% (24658/24658), done.
fatal: invalid reference: f985bee
CMake Error at mbedcrypto-subbuild/mbedcrypto-populate-prefix/tmp/mbedcrypto-populate-gitclone.cmake:40 (message):
Failed to checkout tag: 'f985bee'
I therefore change the GIT_SHALLOW to FALSE, and it builds. However, another build error come up when applying patches for mbedcrypto.
Checking patch library/psa_crypto.c...
Checking patch library/psa_crypto_driver_wrappers.h...
error: library/psa_crypto_driver_wrappers.h: No such file or directory
Checking patch library/psa_crypto_driver_wrappers_no_static.c...
error: library/psa_crypto_driver_wrappers_no_static.c: No such file or directory
I did checkout commit f985bee and find in fact there is no psa_crypto_driver_wrappers.h. Is it possible that the commit hash is incorrect?
Best regards,
Hao
This email keeps the event up to date in your calendar.
TF-M Tech forum
Every 4 weeks from 8am to 9am on Thursday
Mountain Standard Time - Phoenix
Location
https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz…https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9557079…
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/==…
Info====Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic:
TF-M Tech forum - US Time Zone FriendlyTime: Oct 29, 2020 03:00 PM
Greenwich Mean Time Every 4 weeks on Thu, until
Mar 18, 2021, 6 occurrence(s) Oct 29, 2020 03:00
PM Nov 26, 2020 03:00 PM
Dec 24, 2020 03:00 PM Jan 21, 2021 03:00
PM Feb 18, 2021 03:00 PM
Mar 18, 2021 03:00 PMPlease download and import the following
iCalendar (.ics) files to your calendar system.Weekly:
https://linaro-org.zoom.us/meeting/tJEocOmvpz4tHtYu0Wvn2fOsG91u0kv_ECPd/ics…
Zoom
Meetinghttps://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz09Meeting
ID: 955 7079 5742Passcode: 177658One tap mobile+12532158782,,95570795742#
US (Tacoma)+13462487799,,95570795742# 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)
877 853 5247 US Toll-free
888 788 0099 US Toll-freeMeeting ID: 955 7079 5742Find your local number:
https://linaro-org.zoom.us/u/abx3I7IoRq
Guests
Don Harbin - creator
anton.komlev(a)arm.com
abdelmalek.omar1(a)gmail.com
kevin.townsend(a)linaro.org
seth(a)nxmlabs.com
leonardo.sandoval(a)linaro.org
Joanna Farley
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