- TF-M - lists.trustedfirmware.org

by Ken Liu

Hi, It is reported in a few platforms that the SAU NSC region limit is set 32 bytes larger than expected because the value set did not match the hardware characteristics. The SAU.LADDR treats the last 5 bits as 0x1 which means a valid limit address should be the value with 0x1f in the last bits, take an example if the region starts at 0x1000 with size 0x100, the limit address should be set as 0x1000 + 0x100 - 0x20 which is 0x10E0. The practical region address range is [0x1000 - 0x10FF], all addresses >= 0x1000 and <= 0x10FF would be treated as hitting a region. If your address and size are 32 bytes aligned already, you can just adjust the limit with "start_address + size - 1", as the tailing 5 bits would be masked. Take this patch as an example: Platform: Fix the Veneer SAU region for Arm platforms (I2692f318) · Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/18547> Now only the NSC region is affected, but please check your platform if you are using SAU to see if each region is set properly. Thanks. /Ken

2 years, 11 months

1
0
0 0

TF-M Open CI Down

by Xinyu Zhang

Hi, Sorry to inform you that TF-M Open CI is down. We are trying hard to fix. We'll let you know once it is back to normal. Best Regards, Xinyu

2 years, 12 months

1
1
0 0

Multi slot queue in bare metal NSPE

by Bohdan.Hunko＠infineon.com

Hi all, TFM in current implementation has following condition in tfm_ns_mailbox.h #if !defined(TFM_MULTI_CORE_NS_OS) && (NUM_MAILBOX_QUEUE_SLOT > 1) #error "NUM_MAILBOX_QUEUE_SLOT should be set to 1 for NS bare metal environment" #endif I was wondering whether this is real restriction or this check can be removed. I am not mailbox expert so please correct me if I am wrong. Quick look at the code shows that it should be ok to have multi slot queue in bare metal environment, with the note that only one slot will be used (as there is only one thread). If my understanding is correct then it would be nice to remove this compile time check (I am happy to provide a patch for it). We need this change because we deliver TFM as prebuilt binary and interface (one installed after the build). This binary is built with NUM_MAILBOX_QUEUE_SLOT = 4, so in current implementation it cant be used in bare metal environment. 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 years

2
1
0 0

FW: [Maintenance] - ci.trustedfirmware.org down time 2022-12-16

by Xinyu Zhang

Hi, FYI. TF-M Open CI will be on maintenance on 16th Dec. Time to stop triggering new jobs: 2022-12-16 18:00 UTC Maintenance end time: 2022-12-16 22:00 UTC Regards, Xinyu From: Kelley Spoon via Tf-openci-triage <tf-openci-triage(a)lists.trustedfirmware.org> Sent: Thursday, December 15, 2022 4:16 AM To: tf-openci(a)lists.trustedfirmware.org; tf-openci-triage(a)lists.trustedfirmware.org Subject: [Tf-openci-triage] [Maintenance] - ci.trustedfirmware.org down time 2022-12-16 Hello All, The server will be offline to start a maintenance window on 2022-12-16 at 20:00 UTC. Jenkins will be put into "Shutdown Mode" at 2022-12-16 18:00 UTC to stop accepting new jobs and allow executing tasks to complete. This downtime is required to execute an upgrade for Jenkins to address some security advisories and enable new functionality. Emails will be sent prior to and following the upgrade to provide status reports. Start: 2022 12-16 20:00 UTC End: 2022-12-16 22:00 UTC Regards, -- Kelley Spoon <kelley.spoon(a)linaro.org<mailto:kelley.spoon@linaro.org>>

3 years

1
0
0 0

TF-M Open CI is Down

by Xinyu Zhang

Hi, Sorry to inform you that TF-M Open CI is currently down for the time being. We'll let you know once it is back to normal. Best Regards, Xinyu

3 years

1
1
0 0

TF-M release v1.7.0 announcement

by Anton Komlev

Hello, I am pleased to announce the release of TF-M v1.7.0. New major features are: * Unified API to PSA Service access implementing PSA FF-M and FF-M v1.1 extension * The Library model is deprecated and removed * Improve and simplify TF-M configurability * Introduce the base configuration for TF-M essential * Shift config options from CMake to C header files for PSA modules and platforms * Employ Kconfig as a configuration tool and dependency tracker * Configurable stack size for Secure Partitions * Add TF-M Medium-ARoT-less profile * MM-IOVEC deployed in PSA Secure Partitions * PSA FWU API updated to v1.0 * Mbed TLS updated to v3.2.1 * Code size further optimised * The manifest tool is decoupled with the build system * Improvements in the Code size analysis tool * Updated documentation It is tagged with TF-Mv1.7.0<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tag/?h=TF-Mv1.7…>. The release time changes will be integrated with the main branch shortly. Many thanks everyone for contribution, review and support this milestone. Anton

3 years

1
0
0 0

TF-M and communication stack in NSPE

by Romain JAYLES

Hello, We are currently integrating a protocol stack with a Radio IRQ in a TrustZone environment with the TF-M as the SPE. The Radio IRQ requires fast treatment from our protocol stack, the need is to have the Radio IRQ handled with the lowest latency possible. The fact that all the IRQs in the NonSecure side can't preempt IRQ on the Secure side in the TF-M design leads us to the following possibilities with several limitations: 1. Having the Radio IRQ as the lowest priority on the NonSecure side: if a user creates its own partition with an IRQ (which by design will have a lower priority of our IRQ because it's in the Secure side), it could potentially delay for too long the Radio IRQ processing, thus leading to Radio protocol related issues. 1. Having the protocol stack related to the Radio IRQ in a partition directly in Secure side : this configuration is highly disputable from a Security point of view, the possibility to introduce a Security flaw with the protocol stack in Secure being too high. 1. Having the Radio IRQ in a Secure partition (FLIH for faster handling) and forward the IRQ handling to the protocol stack in the NonSecure side, all modifications to the NVIC registers of this Radio IRQ (enable, disable, priority level) requested by the protocol stack in NonSecure side will have to be done through this partition with TF-M API calls (SFN backend for execution performances) : This configuration will probably led to issues such as reentrancy on the TF-M (for example if the TF-M forward an IRQ to the NonSecure which then calls TF-M API for Radio NVIC register manipulations) or having to call TF-M from NonSecure in handler mode. Do you already have experienced with this type of problematics, or do you see TF-M configurations which will be more suitable for such a use-case ? Thank you, Regards, Romain ST Restricted

3 years

3
6
0 0

TF-M threat modeling diagrams

by Bohdan.Hunko＠infineon.com

Hi all, Our team is working on TFM threat modeling, we are analyzing existing code to find and fix any security issues/problems with it. To better perform this modeling we are interested in having detailed diagrams of TFM boot and execution flows. Ideally the diagrams should be quite detailed to show system state transitions, detailed execution flow and any actions that are not obvious when first looking into TFM code (e.g. scheduling of nested calls, execution of secure IRQs that interrupt nested scheduling, ....). Does TFM community have such (or similar) diagrams/? If so then where can we find them? We think that these diagrams may be very useful to TFM in general. They will let TFM users easily understand how TFM works (in details). 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 years

2
1
0 0

Start of TF-M v1.7.0 release process

by Anton Komlev

Hello, The branch release/1.7.x<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/log/?h=release/…> has been created indicating the start of the release process and features freeze. RC1 tag will follow after successful run of the basic tests. Let me remind that the code is not frozen, and development can be continued on the main branch. Thanks, Anton

3 years

1
3
0 0

CMake 3.25.0 build issue

by Bøe, Sebastian

Hi, when I updated from CMake 3.24.0 to the new (two weeks old) CMake 3.25.0 I am no longer able to build TF-M with -DTEST_PSA_API=CRYPTO. (Downgrading CMake fixes the issue) Is there an interoperability issue with the latest CMake release and the TF-M build system? Reproduced with TF-Mv1.7.0-RC1 TF-Mv1.6.0 Steps to reproduce: 1. install CMake 3.25.0. 1. cd trusted-firmware-m 1. rm -rf cmake_build && cmake -G Ninja -S . -B cmake_build -DTEST_PSA_API=CRYPTO -DTFM_PLATFORM=nordic_nrf/nrf5340dk_nrf5340_cpuapp -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug && ninja -C cmake_build Only reproduces with TEST_PSA_API and CMake 3.25.0. Builds fine with 3.24.0 or non-PSA API builds. error: file INSTALL cannot find "/home/sebo/ncs/modules/tee/tf-m/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/src/psa_generate_database-build/target_database.h": No such file or directory.

3 years

3
2
0 0

Trusted Firmware M build error on Windows 10

by Pocsai Ildiko LCPF-CH

Hello, I'm trying to build the Trusted Firmware M on Win10 x64 for NXP LPC55S69 using the IAR compiler, but I get the following error: [ 76%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/platform/ext/target/nxp/lpcxpresso55s69/Device/Source/startup_lpcxpresso55s69.o extern uint32_t __INITIAL_SP; ^ "C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",29 Error[Pe007]: unrecognized token extern uint32_t __INITIAL_SP; ^ "C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",29 Error[Pe065]: expected a ";" extern uint32_t __INITIAL_SP; ^ "C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",29 Error[Pe007]: unrecognized token extern uint32_t __STACK_LIMIT; ^ "C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",30 Error[Pe007]: unrecognized token extern uint32_t __STACK_LIMIT; ^ "C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",30 Error[Pe065]: expected a ";" extern uint32_t __STACK_LIMIT; ^ "C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",30 Error[Pe007]: unrecognized token (VECTOR_TABLE_Type)(&__INITIAL_SP), /* Initial Stack Pointer */ In the attachment, you can find the full build log and also the CMake build file generation log. Some details about my setup: Win10 Enterprise x64. Version 20H2 IAR ANSI C/C++ Compiler V8.50.9.278/W32 for ARM GNU Make 3.81 git version 2.36.0.windows.1 CMake 3.24.2 Python 3.10.5 I followed the steps from the Getting started guide here<https://tf-m-user-guide.trustedfirmware.org/getting_started/index.html> than the steps to build the framework for LPC55S69 here<https://tf-m-user-guide.trustedfirmware.org/platform/nxp/lpcxpresso55s69/RE…>. Do you have any idea what I'm missing? In case you need any further information let me please know. Thanks in advance. Kind regards, Ildikó Pocsai

3 years

6
11
0 0

Number context for NS

by Michel JAOUEN

Hello, I see that in coming 1.7.0 the file secure_fw/spm/ns_client_ext/tfm_ns_ctx.h contains a comment /* Supported maximum context for NS. Only support single context for now. */ #define TFM_NS_CONTEXT_MAX 1 Does it mean that several simultaneous NSC call is not supported ? Best regards ST Restricted

3 years

2
1
0 0

Interrupt SLIH Scheduling

by vivahavey＠gmail.com

Dear developers, I have a question about interrupt SLIH scheduling in IPC model. Assume that there are two secure partitions P1 and P2, and P1 has higher priority than P2. P1 calls psa_call(), so SPM blocks P1 and wakes up P2 to execute P2's service handler. Now P2 is running. Suddenly P1's interrupt occuerred, and P1's SLIH signal is asserted for more processing. A shedule request is also triggered. Since P1 has higher priority than P2, will P2 be preemted by P1 to execute P1's SLIH immediately? If the answer is yes, the psa_call() chain will be corrupted, right? Thanks in advance. Alvin Chang

3 years

3
3
0 0

Platform/Application specific service extension

by Roman.Mazurak＠infineon.com

Hi, Partition is described through configuration in YAML files (manifests). This configuration includes following properties (see Adding Secure Partition - Add manifest<https://tf-m-user-guide.trustedfirmware.org/integration_guide/services/tfm_…>): * Name, type, priority, model, ... * List of services provided by partition * MMIO regions * List of IRQs * Dependencies Each platform should provide implementation of HAL which is specific to standard partitions like Crypto, ITS, etc. It's mandatory to provide proper isolation of memory/peripheral that are used by platform specific code that provides HAL implementation or add a custom dependency for standard partition. Currently platform can use following approaches to resolve the problem of extending YAML of standard TF-M partition: * Create a platform specific copy of partition YAML, see https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15639 as an example of such approach. * Modify standard partition by introducing optional fields, see https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/17718. These both solution are not flexible enough. It requires to modify platform independent code or maintain own copy of partition YAML file with needed changes. I think it make sense to integrate partition YAML extension tool in TF-M. Platform/application should be able to provide manifest-extension file(s). Such manifest-extension file may provide additional properties which should be joined with properties provided by standard partition manifest files. For example to solve problem for https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15639 ARM RSS platform may provide following manifest-extension file with structure like this: { "extensions": [ { "name": "TFM_SP_INITIAL_ATTESTATION", "dependencies": [ "TFM_MEASURED_BOOT" ] } ] } Tool which parses manifests should add a new dependency on "TFM_MEASURED_BOOT" to list of dependencies for "TFM_SP_INITIAL_ATTESTATION" partition. Please, share your opinion on this topic. Best regards, Roman.

3 years

2
1
0 0

Deleting last object in a data block in ITS filesystem

by Stefan Krug

Hello! Seemingly, there is an issue with file deletion in ITS. I would think it is not possible to delete the last object in a data block (so that the data block becomes empty). It's easiest to reproduce with using large objects (because then the number of involved objects is small), but would also happen with multiple smaller objects: With the following flash configuration: ITS_MAX_ASSET_SIZE=0x1000 TFM_HAL_ITS_SECTORS_PER_BLOCK=1 TFM_HAL_ITS_FLASH_AREA_SIZE=0x20000 TFM_HAL_ITS_PROGRAM_UNIT=0x100 ITS_FLASH_NAND_BUF_SIZE=1*0x1000 In a sequence of writing and deleting an object like: const uint8_t big_file[ITS_MAX_ASSET_SIZE] = {0}; status = psa_its_set(uid, sizeof(big_file), big_file, flags); status = psa_its_remove(uid); deleting the file fails with the status of PSA_ERROR_GENERIC_ERROR. What I think happens is: Due to the size of the file, it does not fit in the metadata block, and is put a second (data only) block. The object is written there as expected. When the data block is deleted later, an attempt is being made to compact it with its_flash_fs_dblock_compact_block(). However, there is no data to keep before the object to be deleted and also no data to keep after it, this block will become empty, so no call to its_flash_fs_block_to_block_move() happens, which causes no call to fs_ctx->ops->write() happens. Now the flash driver in my case is a buffering its_flash_nand.c. In the write() call it would associate a buffer for the physical sector to write. But since there is no write() call the subsequent fs_ctx->ops->flush() fails as it has no buffer to flush out. I believe no compaction of the block should even be attempted - it is known that the block will be empty beforehand. Perhaps similar to https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/17578, this is yet another reason to skip compacting of the block? It would be very much appreciated if one of the experts could confirm this suspicious behavior or point out a mistake I am making. Thank you very much, best regards Stefan Krug

3 years, 1 month

2
1
0 0

Announcing TF-Mv1.6.1 fix

by Anton Komlev

Hello, This is an announcement of TF-M v1.6.1 hotfix preparation. The reason for the hot fix is the recently found incorrect stack sealing in Library model. The library mode is deprecated already but is available in v1.6.0 and the intention is to leave it in the best shape to our knowledge. Security analysis shows no vulnerability was brought by this defect, so it is not a security fix. The plan is to issue the fix by Nov 17. TF-M release cadence and process is here: https://tf-m-user-guide.trustedfirmware.org/releases/release_process.htmlte… Thanks, Anton

3 years, 1 month

1
1
0 0

TF-M Profile Medium-ARoT-less

by David Hu

Hi all, TF-M Profile Medium-ARoT-less is proposed to align with PSA Certified ARoT-less Level 2 protection profile [1]. May I ask for your review and comment please? Please check following patches: https://review.trustedfirmware.org/q/topic:%22arot-less%22+(status:open%20O… Any feedback is welcome. [1] https://www.psacertified.org/app/uploads/2022/10/JSADEN019-PSA_Certified_Le… Best regards, Hu Ziji

3 years, 1 month

1
0
0 0

Lost data when overwriting object using its_set?

by Stefan Krug

Hello! While playing around with TF-M I have stumbled upon unexpected behavior: In a sequence of ITS api calls like: a.) psa_its_set(TEST_UID_1, sizeof(write_data_1), write_data_1, PSA_STORAGE_FLAG_NONE); b.) psa_its_set(TEST_UID_2, 0, NULL, PSA_STORAGE_FLAG_NONE); c.) psa_its_remove(TEST_UID_1); d.) psa_its_set(TEST_UID_2, sizeof(write_data_2), write_data_2, PSA_STORAGE_FLAG_NONE); e.) psa_its_get(TEST_UID_2, 0, sizeof(read_data_2), read_data_2, &read_data_length); with #define TEST_UID_1 2U #define TEST_UID_2 3U const uint8_t write_data_1[] = "ONE"; const uint8_t write_data_2[] = "TWO"; It seems that step e) does not return the data written in step d). I believe I have root-caused it to an issue in its_flash_delete_idx() (see below), but since this is a rather straightforward API call sequence, I wonder whether this is not rather an issue in my environment and would be glad if someone could confirm it or point me to a direction of a potential different cause? I am using TF-M version 1.6, a nor flash with (erase) block size 0x1000 bytes and a program unit size (page size) of 0x100 bytes. Thank you, best regards Stefan Krug More analysis details: After step c) there will be the following relevant metadata blocks in the filesystem: 1.) unused metadata block (used to have the metadata of TEST_UID_1) 2.) metadata block of TEST_UID_2 During step d) the update of TEST_UID_2 is done in two steps - first step is to write metadata + content of TEST_UID_2. After this step, the metadata blocks look like: 1.) NEW metadata block of TEST_UID_2 2.) old metadata block of TEST_UID_2 (indicating TEST_UID_2 to be erased) The second step is to delete the outdated file, and compact/defragment the data in the file system. This is done in its_flash_fs_delete_idx(). its_flash_fs_delete_idx will collect the amount of data bytes to preserve. There are two parts of data to be preserved, a chunk of data before the deleted file (of size del_file_data_idx) and a chunk of data after the deleted file. Calculation of del_file_data_idx is done by taking the start offset of the to-be-deleted file. In this particular situation the start of the old TEST_UID_2 is the same as the start of the new TEST_UID_2. The subsequent its_flash_fs_dblock_compact_block will only keep data up to del_file_data_idx - in this case it will NOT keep the data of the new TEST_UID_2 - this data is lost.

3 years, 1 month

2
1
0 0

Latest status of S/NS build split PoC

by David Hu

Hi all, I rebase and update the S/NS build split PoC as requests. Could you please take a look at the latest patch set if you are interested? Trusted-firmware-m part: https://review.trustedfirmware.org/q/project:TF-M%252Ftrusted-firmware-m+br… Tf-m-tests part: https://review.trustedfirmware.org/q/project:TF-M%252Ftf-m-tests+branch:mas… The general idea was presented in https://www.trustedfirmware.org/docs/tf-m_forum_20220120_Restructure_TF-M_b… while some details are improved in code. Any comment and feedback is welcome! Best regards, Hu Ziji

3 years, 1 month

1
0
0 0

TFM_PARTITION_AUDIT_LOG references in the code after Lib Model deprecation

by Bohdan.Hunko＠infineon.com

Hi all, TFM Library model has been deprecated, thus AUDIT logging partition has been deleted, but I still see a reference to that partition in config/check_config.cmake lines 102-103: #Audit log is not supported in IPC model, disable it by default tfm_invalid_config(TFM_PARTITION_AUDIT_LOG) Looks like this should be removed or comment fixed. An I missing something or this is a mistake that should be fixed? 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 years, 1 month

3
2
0 0

an521 L3 protection setting questions

by Bohdan.Hunko＠infineon.com

Hi all, I have a few questions regarding an521 platform protection settings for Level 3 isolation. In platform/ext/target/arm/mps2/an521/tfm_hal_isolation.c there is an const static struct mpu_armv8m_region_cfg_t region_cfg[] - for L3 it specifies to protect: * Code (from Image$$PT_RO_START$$Base to Image$$PT_RO_END$$Base) to be accessible in both PRIV and UNPRIV states. * PSA RoT partitions data in RAM (from Image$$PT_PRIV_RWZI_START$$Base to Image$$PT_PRIV_RWZI_END$$Base)to be accessible only in UNPRIV state. * TFM_SP_META_PTR to be accessible in both PRIV and UNPRIV states. Also in this file mpu_armv8m_enable() function call specifies PRIVILEGED_DEFAULT_ENABLE for MPU. I have following question to this configuration * Does this configuration mean that in L3 PSA RoT code is not isolated from APP RoT (APP RoT can read/execute PSA RoT domain code)? * How SPM data (TFM_BSS and TFM_DATA sections from scatter file) is protected? I cant see it being protected by MPU. * Is it skipped because PRIVILEGED_DEFAULT_ENABLE is set which means that SPM will be able to access this data and this allows to save one MPU region? * If so then why MPU region is used for PSA RoT partitions data? 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 years, 1 month

2
2
0 0

[RFC]Library Model deprecation

by Summer Qin

Hi, We plan to merge Library Model deprecation patches<https://review.trustedfirmware.org/q/topic:%22library-model-deprecation%22+…> this Friday since some other development work depends on this. May I ask for a review on these patches? Best Regards, Summer

3 years, 1 month

2
1
0 0

Open CI Infrastructure in Maintenance

by Xinyu Zhang

Hi, Open CI infrastructure is in an emergency maintenance. Tests will be impacted. I'll let you know once it is back to normal. Best Regards, Xinyu

3 years, 1 month

1
1
0 0

State of Extra tests

by Bohdan.Hunko＠infineon.com

Hi all, I have tried building Extra S and NS tests from tf-m-extras repo for PSoC64 and the result I got is that device prints message that extra S test started and reboots. Here is the command line I used: cmake -S . -B build_psoc64 -G "Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DTFM_LVL=2 -DEXTRA_S_TEST_SUITES_PATHS=< tf-m-extras path>/examples/extra_test_suites_example/extra_s -DEXTRA_NS_TEST_SUITES_PATHS=<tf-m-extras path>/examples/extra_test_suites_example/extra_ns I have also tries building with following command line (same as before but -DTEST_S=ON and -DTEST_NS=ON added): cmake -S . -B build_psoc64 -G "Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DTFM_LVL=2 -DEXTRA_S_TEST_SUITES_PATHS=< tf-m-extras path>/examples/extra_test_suites_example/extra_s -DEXTRA_NS_TEST_SUITES_PATHS=<tf-m-extras path>/examples/extra_test_suites_example/extra_ns -DTEST_S=ON -DTEST_NS=ON The result is the same - message about starting Extra S test suite is printed and then device reboots. Could someone please test it on other platform and let me know whether Extra S and NS tests works there. 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 years, 1 month

2
1
0 0

Use original CMSIS files

by david.hazi＠arm.com

Hi all, We've created a change, which is using original CMSIS headers in TF-M. Current patch is only for arm/mps3/an552 platform. Our plan is to create a public review only for this (which will NOT be merged), and after the review, we would like to extend this patch to all of the platforms. The main changes in the chain: - copy and zero_table size fix in the GNU linker scripts and initial startup code - Removed __INITIAL_SP and __STACK_LIMIT patch form gcc and iar cmsis files, NS linker scripts using CMSIS style naming, the secure and bl2 build's linker scripts remains untouched (ARMCLANG style naming, __INITIAL_SP and __STACK_LIMIT patched with cmsis_stack_override interface library) - NS process stack removed from NS linkers (PSP) - Common startup file for bl2 and ns builds - Add original cmsis headers, updated system and startup files - Stack sealing done twice, once from startup (to resemble CMSIS startup template) and once from TF-M secure main Feedback is welcome: https://review.trustedfirmware.org/q/topic:%2522use-original-cmsis-headers%… David Hazi

3 years, 2 months

2
3
0 0

TF-M psa crypto test do not set the algorithms in psa_key_attributes_t

by Swarowsky, Markus

Hello, I was adding sanity checks to the psa_crypto_driver_wrappers to validate bits/type and policy->alg of the given psa_key_attributes_t attributes for the psa_generate_key, psa_import_key, and psa_copy_key calls. To check it the given combination is within the psa specification. In the PSA crypto spec it says: The key permitted-algorithm policy is required for keys that will be used for a cryptographic operation, see Permitted algorithms<https://armmbed.github.io/mbed-crypto/html/api/keys/policy.html#permitted-a…>. [https://armmbed.github.io/mbed-crypto/html/api/keys/management.html?highlig…] Which is most likely the case for all key types except of PSA_KEY_TYPE_RAW_DATA But after adding the sanity checks the TF-M crypto tests(test_c*_testing_* and TFM_S/NS_CRYPTO_TEST_10*) failed. I took a look at these tests, it turned out that they don't set the algorithm flag for the key attributes. My question now is, is the algorithm flag skipped on purpose or just missed during the test case creation as It should be set according to the psa crypto spec? Thanks for the help and the feedback Markus Swarowsky | R & D Engineer M +47 404 66 922 | Trondheim, Norway nordicsemi.com<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nordic…> | devzone.nordicsemi.com<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevzone.n…> Facebook<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.faceb…> | LinkedIn<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linke…> | Twitter<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.c…> | YouTube<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtu…> | Instagram<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.insta…> [Nordic_logo_signature]<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nordic…>

3 years, 2 months

2
5
0 0

TF-M Open CI Unstable

by Xinyu Zhang

Hi, TF-M Open CI is unstable for the time being because of the ArmClang license issue in Jenkins. Sorry for any inconvenience! I'll let you know once it is back to normal. Thanks, Xinyu

3 years, 2 months

1
1
0 0

[RFC]Moving faults handlers to dedicated file

by Kevin Peng

Dear platform owners, I'm moving faults handlers to dedicated files from spm_hal.c as this file should be for Library Model only. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/16858 Please check your platforms respectively. Plan to merge it on next Monday. Best Regards, Kevin

3 years, 2 months

1
0
0 0

Level 3 Isolation improvements

by Bohdan.Hunko＠infineon.com

Hi everyone, I have several questions related to L3 isolation in TFM. First of all, FFM specifies that: * In L3 PSA RoT partitions does not need to be isolated from SPM (and vice versa) * PSA RoT partitions does not need to be isolated from each other * PSA RoT partitions and SPM must be isolated from APP RoT partitions * APP RoT partitions must be isolated from each other This picture from TFM docs<https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/desig…> seem to illustrate statements above. Currently platforms with L3 support (e.g. an521) follow the rules stated above. They achieve this by executing PSA RoT partitions and SPM in privileged mode, and APP RoT partitions in unprivileged mode. Partition boundaries are only updated when switching to APP RoT partition. From description of tfm_hal_activate_boundary (see code here<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…>) and this an521 code<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…> seems like platform can determine whether partition will be executed in privileged or unprivileged mode. So my questions are: 1. For improved isolation in L3 does it make sense to: * isolate SPM from PSA RoT partitions * isolate PSA RoT partitions from each other (like APP RoT partitions are isolated) 1. If question 1 make sense then can platform achieve this improved isolation with current code base? From this an521 code<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…> it seems like platform may set all partitions to be executed in unprivileged mode and dynamically switch boundaries between them (between both PSA and APP RoT partitions). SPM will remain in privileged mode. It seems like this approach is possible with minor changes to SPM. For example this code will need<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…> to be changed to call tfm_hal_activate_boundary regardless of partition privilege level. Are there any other changes needed to make this approach work? 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 years, 2 months

2
5
0 0

Enable stack protection in the regression tests

by Swarowsky, Markus

Hey, While trying to debug a crash in the TF-M regression tests, I noticed that the msplim_ns register is set to 0x0, leaving the non-secure application without any stack to protection, sadly I wasn't able to figure out how to enable the stack protection, which would be nice as we suspect that a stack overflow could cause the crash. Therefore, I would be interested if it possible to enable stack protection for the non-secure application of the TF-M regression tests and if so, how? Thanks for the help Markus Swarowsky | R & D Engineer M +47 404 66 922 | Trondheim, Norway nordicsemi.com<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nordic…> | devzone.nordicsemi.com<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevzone.n…> Facebook<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.faceb…> | LinkedIn<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linke…> | Twitter<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.c…> | YouTube<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtu…> | Instagram<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.insta…> [Nordic_logo_signature]<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nordic…>

3 years, 2 months

5
4
0 0

Partition assets attributes

by Bohdan.Hunko＠infineon.com

Hi everyone, I have several questions related to partition assets attributes. FFM specifies 2 types of assets (mmio_regions): * Named MMIO region * Numbered MMIO region FFM does not really specify the use cases for these 2 different types. I expect that Named region is only used for peripherals and numbered region is only used for memory regions. Am I right here? If no, then what the use cases for these 2 types are and what is currently supported in TFM? Also I see that in tools/templates/partition_load_info.template lines 221-224 ASSET_ATTR_NUMBERED_MMIO or ASSET_ATTR_NAMED_MMIO are assigned for assets from manifest files depending on their type, but tools/templates/partition_load_info.template#187<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/tools/temp…> does not assign any of these attributes for "PART_REGION_ADDR(PT_{{manifest.name}}_PRIVATE, _DATA_START$$Base)" at isolation level 3. Is this some a bug or I am missing some knowledge on this mmio_regions stuff? 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 years, 2 months

2
3
0 0

TF-M Library model deprecation proposal

by Anton Komlev

Hello, Following tech forum today and the presentation on August 18 (to be published asap), I propose to deprecate TF-M library model as an obsolete and replace it with SFN model as a successor. PSA compliant SFN and IPC, defined in FF_M will then be the 2 supported models in TF-M going forward. Please share your thoughts and concerns on the proposal. Having no objections, we will depreciate the Library model after October 1 and it will be removed in TF-M v1.7.0 Thanks, and best regards, Anton

3 years, 2 months

1
1
0 0

Template implementations used in production

by Bøe, Sebastian

Hi, we wish to avoid the pitfalls of "doing your own security", and at the same time not use dummy/template code that is not meant for production. May I ask if it is still accurate what the docs say here about the template folder, namely that nothing in the template folder should be used in production without being ported first? This directory contains platform-independent dummy implementations of the interfaces in platform/include. These implementations can be built directly for initial testing of a platform port, or used as a basic template for a real implementation for a particular target. They must not be used in production systems. $ ls platform/ext/common/template/ attest_hal.c flash_otp_nv_counters_backend.c otp_flash.c tfm_initial_attest_pub_key.c crypto_keys.c flash_otp_nv_counters_backend.h tfm_fih_rng.c tfm_rotpk.c crypto_nv_seed.c nv_counters.c tfm_initial_attestation_key.pem tfm_symmetric_iak.key

3 years, 2 months

2
1
0 0

SFN non-secure interface sources

by Andersson, Joakim

Hi. I was testing the SFN model on the TF-M 1.6 release and I am confused about which API source files should be used for the non-secure application. The documentation here is lacking, so I am going by what we do in the build scripts of TF-M and tf-m-tests. The non-secure source files that are exported and included in the nonsecure API library are tfm_<partition>_ipc_api.c. This strikes me as odd, to use the IPC source files for the SFN model. If this is correct the naming is misleading. From the code the selection is done based on PSA_API definition. Based on this if this is the correct source files to use then I would think this should either be documented or renamed to something that better reflect the use, perhaps tfm_<partition>_psa_api.c? In the documentation there is a lot of room for improvements, the existence of tfm_<partition>_secure_api.c could lead to confusion since it is not always well described. tfm_attestation_integration_guide.rst: System integrators might need to port these interfaces to a custom secure partition manager implementation (SPM). Implementations in TF-M project can be found here: - ``interface/src/tfm_initial_attestation_func_api.c``: non-secure interface implementation for library model - ``interface/src/tfm_initial_attestation_ipc_api.c``: non-secure interface implementation for IPC model - ``secure_fw/partitions/initial_attestation/tfm_attestation_secure_api.c``: secure interface implementation Here it is not clear to me what "secure interface implementation" means, it could be interpreted as the SFN API. tfm_crypto_integration_guide.rst: - ``tfm_crypto_secure_api.c`` : This module implements the PSA Crypto API client interface exposed to the Secure Processing Environment Here it is clearer that tfm_<partition>_secure_api.c is the interface to the SPE. However the documented NSPE interface source file does not even exist, and does not explain the IPC / FUNC difference: | NSPE client API interface | This module exports the client API of PSA Crypto to the NSPE | ``./interface/src/tfm_crypto_api.c`` tfm_fwu_service.rst: | NSPE client API interface | This module exports the client API of PSA Firmware Update to | ``./interface/src/tfm_firmware_update_func_api.c`` | | | the NSPE(i.e. to the applications). | ``./interface/src/tfm_firmware_update_ipc_api.c`` | Here it is mentioned the two possible source files, but it is not specified when to use which source file. Generally: Between all the services this is not consistently listed, for example the tfm_its_service.rst file does not have the table of source files. If there is a general description of the non-secure interface sources, I couldn't find it. -Joakim AnderSSON

3 years, 2 months

2
1
0 0

Failure mode of protected storage with faulty NV counters?

by Jeremy Herbert

Hi, I am not too familiar with TF-M, so please forgive me if this is a silly question. The protected storage APIs appear to require the use of on-die flash to store a non-volatile counter that is used for rollback protection. This is severely limiting in terms of the number of writes, because basically you get as many writes as the endurance of the flash on the MCU (for example, the nordic cortex M33 devices have a rated write endurance of 10k cycles per page, and I don't think there is any wear levelling in TF-M). For example, assuming that a device was configured to write to the protected storage on boot, one could pretty easily exhaust this flash in a few hours by continuously power cycling it. Even if the 10k writes is a very conservative rating, it seems pretty likely that the counter flash will fail before UINT32_MAX. My question is: what happens to the security and functionality of the protected storage if the internal NV flash write fails silently? I don't know much about the semiconductor physics at play here, but presumably it could fail to make the counter a constant number, or fail to a random number. I had a quick look but there don't appear to be any checks in the code to ensure that a value was actually written correctly to the NV counters flash in case of silent corruption - it seems to just assume that any error would be detectable by some return code from the flash write driver. I was looking for some check like: if (value_to_write != value_read_back) return FLASH_WORN_OUT_ERROR; But I wasn't able to find it. So assuming it isn't actually there, if the counter fails to a constant (which is not UINT32_MAX) then presumably the rollback protection would be broken for all writes after that point (and maybe some before depending on the constant). If it fails to a random number, then it would be broken in a more "random" way - ie it would randomly work/not work depending on the value of the counter, until all UINT32_MAX numbers are randomly selected as the counter value. Also, given that typical AEAD ciphers like AES-GCM typically fail catastrophically with nonce reuse and the protected storage is indeed AEAD (though I can't quite work out yet which cipher is used), if these non-volatile counters are used to generate a nonce then potentially the encryption of the device could be broken just by rebooting the device until the flash is worn out, and then the nonce will be reused if the flash fails to a constant value. Could someone please help me clear up if my understanding here is correct? As is, I am struggling a bit to understand how to use the protected storage API in a secure way with this constraint, because if an attacker has any way to repeatedly cause a flash write it is basically game over. Any help would be greatly appreciated. Thanks, Jeremy

3 years, 2 months

4
15
0 0

Re: [TF-M] Supporting encryption with ITS

by Sherry Zhang

Hi George, The ITS without encryption is not a compromised RoT. In the PSA Secure Storage API spec, the PSA Internal Trust Storage aims at providing a place for devices to store their most intimate secrets. Also “””””””””””””””””””” 1. The storage underlying the PSA Internal Trusted Storage Service MUST be protected from read and modification by attackers with physical access to the device. 2. The storage underlying the PSA Internal Trusted Storage Service MUST be protected from direct read or write access from software partitions outside of the PSA Root of Trust (PRoT). “””””””””””””””””””” So, for internal trusted storage service, it requires the underlying storage itself should provide being read or write protection. The storage area should be a “trusted” area. Does the storage area on your device meet this requirement? Is the memory physically isolated? If not, I wonder why not uses the Protected Storage service instead? For the design of adding encryption in ITS, in the PS partition, the `iv` and the encrypted object data are stored with the object file while the tag of each object is stored with the object table file. So, if encrypt the PS object in the ITS file system, how the PS partition get the `tag` of each object? After a rough thought, I think probably a standalone encryption for ITS is more reasonable. As this is a relatively “big topic”, would you like to hold a discussion on the TF-M Tech forum if it is not limited by confidential information? The next Tech forum will be hold on this Thursday 3:00 PM UTC time. Regards, Sherry Zhang From: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>> Sent: Friday, September 24, 2021 8:52 PM To: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Supporting encryption with ITS Hello Sherry, Thank you for your input! 1. Our threat model is more concerned about attacks which can happen very early in the boot process, I think. A completely compromised RoT is not in our threat model. 2. I see that, ITS is supposed to store small objects. The storage overhead of adding encryption will be probably bigger than 20 bytes I think but the intention is to have this only as a configuration, not as the default option. 3. Agreed, a HAL API should be used for this. Do you have any opinion on the design of it? Do you think that it adds value to do try to use a common design for the object handling of both PS and ITS or is it better to have it as a standalone thing for the ITS. Regards, George ________________________________ From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>> Sent: Friday, September 24, 2021 11:58 AM To: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-M] Supporting encryption with ITS Hi George, Some comments from my side: 1. Internal trusted storage is part of the Root of Trust domain. If ITS storage device is attacked, then the code flash where the PSA Rot SP locates may also be attacked. Does the thread model of your system require the encryption in ITS? 2. The ITS service is intended to be used to interface to a small piece of storage. Encryption would increase the context for each ITS file. For example, similarly to PS object context, the `IV` which is used in encryption as well as the generated `tag` should be added into each file context. They total together can be about more than 20 bytes. 3. If the encryption is mandatory/ necessary required by the thread model of your system, as discussed, the PSA crypto service should not be called to avoid the circular. I think a HAL API for encryption may be created in ITS for platform implementation defined encryption/decryption. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vasilakis, Georgios via TF-M Sent: Thursday, September 23, 2021 10:47 PM To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; Fabian Schmidt <fabian.schmidt(a)nxp.com<mailto:fabian.schmidt@nxp.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Supporting encryption with ITS Hey Gyorgy, These are very valuable comments! I am aware of the circular dependency issue because the PSA apis are using the ITS as a storage backend. This, as you said, can be circumvented by using a software crypto library or an implementation specific API. So, for the encryption a flexible API can be used which can allow externals to use their own function calls. Regarding the key storage, this is what I had in mind as well, using derived keys from the HUK. So that we don't need to store anything but the crypto metadata. Adding another layer of storage will raise more issues, I think. ________________________________ From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>> Sent: Thursday, September 23, 2021 4:30 PM To: Fabian Schmidt <fabian.schmidt(a)nxp.com<mailto:fabian.schmidt@nxp.com>>; Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-M] Supporting encryption with ITS Hi, AFAIK the main reason for ITS not using encryption is the problem of circular dependency. ITS is used by crypto SP for key storage, so how will crypto fetch the key from ITS to decrypt ITS? You could use a software crypto implementation (another mbed-tls instance) in ITS, but where would you safely store the keys? If you have a two layer ITS, one for only storing the keys for the second instance, and a second, encrypted one, then you end up with something like ITS and PS. You may not need a full blown on-chip FLASH device for ITS. If you have a HUK available, you can derive the same SP specific keys from that at each boot, and store these in RAM backed ITS. You won’t be able to store other keys in ITS in a persistent way of course, but for that you can use PS. Well, something along these lines. Perhaps the TF-M team could help better if you could share some details on why your customer would need encrypted ITS. (A PSA for Cortex-A (TS) maintainer chiming in to a “not his business” discussion here 😉 ) /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Fabian Schmidt via TF-M Sent: September 23, 2021 15:51 To: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Supporting encryption with ITS Hi George, I’m wondering if that would add value. To my understanding, ITS was never designed to be encrypted because of the way it’s supposed to be set up. (It’s Internal Trusted Storage.) I believe best practice is to place it in a “trusted” location, one that is ideally only accessible from Secure world, and also ideally on-die. If you then restrict outside access to the internal flash (JTAG, flash programmer ports,…), you’re pretty golden, in that no unauthorized party should be able to read from or write to the ITS.* Let me know if I misunderstand anything about ITS or TrustZone, but that’s my view. Maybe I’m painting an idealized picture. Greetings, Fabian Schmidt * at least short of a sophisticated physical attack or finding some loophole in TrustZone… From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vasilakis, Georgios via TF-M Sent: Donnerstag, 23. September 2021 15:28 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [EXT] [TF-M] Supporting encryption with ITS Caution: EXT Email Hey all, Lately the requirement for an encrypted ITS solution is being asked from our customers and I would like to have a discussion here on how we can design this in a reasonable way. The first thought that came to my mind was to add the functionality to the ITS flash-fs layer. This layer contains file metadata in the its_file_meta_t structure and it should be possible to expand this to include additional crypto metadata (conditionally). This seems to be the less invasive change to me, even though it will introduce some increased memory usage since supporting encryption will mean that we cannot read the data in chunks anymore, we will have to use static buffers. At the same time, I looked at the PS partition since I knew that it has support for encryption. I believe that some core concepts of both solutions have similarities even though the code is quite different. For example, a file in ITS is similar to an object in PS and the (linear) list of file metadata in ITS is similar to the concept of the object table in PS. So, I think that it should be possible to design some generic-enough APIs that we can use for both the ITS and PS. Even though this will require some major refactoring in both partitions, it will decrease the code of these services which will probably decrease maintenance later. What are your thoughts on this? Regards, George

3 years, 3 months

6
16
0 0

Re: Status of RSS platform?

by Maulik Patel

Hi Chris, RSS build requires new runtime Measured Boot Service. This service partition is not yet part of PSA specification and hence it resides in the tf-m-extras repository. (https://git.trustedfirmware.org/TF-M/tf-m-extras.git/) For out of tree partition build, if you map the tf-m-extras repo and provideTFM_EXTRA_MANIFEST_LIST_FILES =<path_to_measured_boot_manifest_list.yaml> and TFM_EXTRA_PARTITION_PATHS=<path_to_measured_boot_partition> (example as below), then it should fix build issue. -DTFM_EXTRA_MANIFEST_LIST_FILES=../../tf-m-extras/partitions/measured_boot/measured_boot_manifest_list.yaml -DTFM_EXTRA_PARTITION_PATHS=../../tf-m-extras/partitions/measured_boot If the error persists, could you please send me the build options you are using and I'll look into this further. Best Regards, Maulik ________________________________ From: tf-m-request(a)lists.trustedfirmware.org <tf-m-request(a)lists.trustedfirmware.org> Sent: Wednesday, September 7, 2022 1:00 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: TF-M Digest, Vol 47, Issue 7 Send TF-M mailing list submissions to tf-m(a)lists.trustedfirmware.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to tf-m-request(a)lists.trustedfirmware.org You can reach the person managing the list at tf-m-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TF-M digest..." Today's Topics: 1. Status of RSS platform? (Chris.Brand(a)infineon.com) ---------------------------------------------------------------------- Message: 1 Date: Tue, 6 Sep 2022 21:48:05 +0000 From: <Chris.Brand(a)infineon.com> Subject: [TF-M] Status of RSS platform? To: <tf-m(a)lists.trustedfirmware.org> Message-ID: <2441d128df93483abc1da39c38e89885(a)infineon.com> Content-Type: multipart/alternative; boundary="_000_2441d128df93483abc1da39c38e89885infineoncom_" Hi, I'm wondering what the status of the RSS platform is. I tried to build it from the current HEAD of master and also from a few earlier commits, and cannot get it to build (I get an error about TFM_MEASURED_BOOT_SID being undeclared in some of the generated code). I was curious about the implementation of tfm_hal_get_mem_security_attr(), tfm_hal_get_secure_access_attr() and tfm_hal_get_ns_access_attr() on an ARMv8 multi-core platform, but there doesn't currently seem to be an implementation of those HAL functions. Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> International Place 13700 V6V 2X8 Richmond Canada www.infineon.com<www.cypress.com<http://www.cypress.com>> www.cypress.com<http://www.cypress.com> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies> Part of your life. Part of tomorrow. NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.

3 years, 3 months

3
3
0 0

TF-M configurability

by Anton Komlev

Hello, Recently we discussed the movement of relevant options into C header files as a potential configuration improvement. By this mail thread, I would like to provoke discussion on what else we are lacking in TF-M configurability and thoughts to make it better. Please share your ideas to review them in the upcoming tech forum. Thanks, Anton

3 years, 3 months

2
2
0 0

Status of RSS platform?

by Chris.Brand＠infineon.com

Hi, I'm wondering what the status of the RSS platform is. I tried to build it from the current HEAD of master and also from a few earlier commits, and cannot get it to build (I get an error about TFM_MEASURED_BOOT_SID being undeclared in some of the generated code). I was curious about the implementation of tfm_hal_get_mem_security_attr(), tfm_hal_get_secure_access_attr() and tfm_hal_get_ns_access_attr() on an ARMv8 multi-core platform, but there doesn't currently seem to be an implementation of those HAL functions. Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> International Place 13700 V6V 2X8 Richmond Canada www.infineon.com<www.cypress.com> www.cypress.com<http://www.cypress.com> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies> Part of your life. Part of tomorrow. NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.

3 years, 3 months

2
1
0 0

Reproducible test builds

by Bøe, Sebastian

Hello, when building TF-M you get the same result no matter what computer you build from assuming all the tooling is the same version. The builds are reproducible in other words. But when building TF-M together with the tests, e.g. by building the regression test suite you will get a different binary depending on where in the filesystem the tf-m-tests repository has been installed. This is because the TEST_FAIL macro uses the gcc macro _FILE_ which injects the absolute paths of source files into strings in the binary. This is a big problem for people using CI systems as a different sized binary can affect race conditions, flash region usage overflows, etc.. I think we should make builds reproducible by default, possibly with a configuration for adding absolute paths into the binary for those that prefer so. I would like to write a patch to this affect, but would prefer to get some feedback now so I don't have to re-write it in review. The simplest solution is to remove __FILE__ from the TEST_FAIL macro,but this would remove useful information and may also fail in the future if someone else uses __FILE__. The more common way of solving this problem is to add a flag to the compiler that instructs it to replace any occurrences of the absolute path with something else during macro expansion. For instance replace "C:/repos/tf-m-tests/source_file.c" with "TFM_TESTS/source_file.c". For gcc the flag is -fmacro-prefix-map=<old_string>=<new_string>. I don't know what the flag is for the other supported compilers or if they support it at all. Would it be OK to only support reproducible builds for the compilers that support an equivalent of macro-prefix-map?

3 years, 3 months

2
4
0 0

What do you think using configuration headers in TF-M ?

by Anton Komlev

Hello, TF-M has many options to configure. All of them are declared as a CMake variables and many of them translated to compiler definitions later. Since the idea of TF-M configuration via config header file(s) was warmly received on the last tech forum I would like to check with community opinion on such hypothetical move: Configure TF-M via definitions in header files while leave CMake for a building control only. Please share your thoughts, opinions and the possible dependencies. Thanks, Anton

3 years, 3 months

6
9
0 0

[RFC] Fault Injection Hardening (FIH) re-enablement on AN521 are ready for review

by Ken Liu

Hello, The FIH functionality reference implementation on AN521 was there before, and then get turned off last year because it increases the effort of updating the HAL interface. Now the HAL interface update is done, this functionality is re-enabled on AN521, based on the updated HAL. The patches are pushed for your review: https://review.trustedfirmware.org/q/topic:%22FIH_AN521_RE%22+(status:open%… The mechanism is mainly the same as the previous implementation, The document is under modifying to reflect the re-enablement changes but still can be read to recall the general concept: https://tf-m-user-guide.trustedfirmware.org/technical_references/design_doc… Please leave your comments in the patches or do overall discussions in this mail thread. Thanks! /Ken

3 years, 3 months

1
0
0 0

AN524 Flash_Driver issue consult

by jidong.mei＠armchina.com

Hi All : I'm developing Flash Driver for TF-M AN524 demo , and trobuled by some code logic . It's that : For , AN524 , PS storage Area is redirect to BRAM , so PS area related read and write can be done using memcpy without Flash driver being implementened . see : platform/ext/target/arm/mps3/an524/cmsis_driver/Driver_Flash.c /* Redirecting PS storage to BRAM */ if (addr >= FLASH_REDIRECT_BASE && addr <= FLASH_REDIRECT_LIMIT) { start_addr = FLASH_REDIRECT_DEST + (addr - FLASH_REDIRECT_BASE); /* PS Flash is emulated over BRAM. use memcpy function. */ memcpy((void *)start_addr, data, cnt); } else { /* Flash driver for QSPI is not ready */ return ARM_DRIVER_ERROR_UNSUPPORTED; } My question is : What the purpose of "else" branch above ? After I implement QSPI driver , in "if" branch , I remove redirect operation , and use Flash Write APIs to replace memcpy func. Then , shoud "else" branch be removed? Or , should I put Flash write driver in "else" branch , and keep "if" branch the same with origion? Best regards, Jidong Mei

3 years, 3 months

2
2
0 0

CMSIS in TF-M

by Chris.Brand＠infineon.com

TF-M includes platform/ext/cmsis, which is CMSIS v5.9.0 with some TF-M-specific changes. Looking at the history for that directory, it seems that we periodically update it and have to re-apply the TF-M-specific changes (which looks to be the naming of the stack and the copy table size). I'm wondering whether there's a plan to either push the TF-M changes into upstream CMSIS or to change TF-M so that they're not needed? It would be nice to just pull CMSIS from upstream like we do with other external libraries... Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> International Place 13700 V6V 2X8 Richmond Canada www.infineon.com<www.cypress.com> www.cypress.com<http://www.cypress.com> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies> Part of your life. Part of tomorrow. NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.

3 years, 4 months

2
1
0 0

ITS/PS improvements

by Roman.Mazurak＠infineon.com

Hello all, I made a patch (https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/16214) that reorganize interaction between ITS partition, ITS file system and ITS flash driver. 1. ITS flash driver interface is decoupled from ITS file system. 2. ITS flash driver interface isn't dependent on upper layers like ITS FS or ITS. 3. ITS flash driver emulated in RAM (its_flash_ram) can be used without CMSIS flash driver even in production environment if needed. 4. Target can provide own implementation of ITS flash driver without implementing CMSIS flash driver. Which can be more flexible or simple in some cases. 5. Allocation of ITS flash driver instance by ITS partition is not dependent on lower layers like CMSIS driver. ITS partition uses abstract flash driver interface to bind ITS file system and driver instance. This changes gives following benefits. 1. Vendors can provide ITS flash driver without need to create an intermediate CMSIS flash driver. 2. It's possible to implement ITS encryption by adding a new ITS flash driver that performs encryption and uses existing drivers (NOR, NAND, RAM, platform specific) as the storage backend. 3. It's possible to use ITS file system + ITS encryption driver (b) for Protected Storage directly without additional context switching during access to PS file system handled by ITS partition. I think it should improve performance of PS. 4. Use ITS file system directly in application specific custom partitions by allocating ITS file system context and ITS flash driver. Best regards, Roman.

3 years, 4 months

1
0
0 0

Service vs Partition wording in manifest files

by Bohdan.Hunko＠infineon.com

Hi everyone, From what I see manifest lists (e.g. tools/tfm_manifest_list.yaml) describe partitions, but "name" field there (which is a description of the partition) uses "Service" word, for example: "name": "Protected Storage Service", Shouldn't this be "name": "Protected Storage Partition" ? Why do TFM uses Service when describing the Partition? 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 years, 4 months

3
12
0 0

TF-M Tech Forum minutes / upcoming Tech Forums calendar

by Don Harbin

Hi All, A gentle reminder that past TF-M Tech Forum minutes/recordings including the last one from August 4th can be found *here <https://www.trustedfirmware.org/meetings/tf-m-technical-forum/>* . Also, the public calendar that includes upcoming TF-M tech forums can be found *here* <https://www.trustedfirmware.org/meetings/>. Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

3 years, 4 months

1
0
0 0

Request about local test with IAR compiler

by Jianliang Shen

Hi, I made a patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/16106> to change CMSIS-RTOS RTX library attribute for ARMv8-M Mainline platforms in TF-M, the reference is CMSIS-RTOS2<https://www.keil.com/pack/doc/CMSIS/RTOS2/html/pDirectory_Files.html#libFil…>. As CI doesn't cover IAR compiler, I'm very grateful if someone who is convenient can help me build and run it with IAR toolchain locally. Best Regards Jianliang Shen

3 years, 4 months

1
0
0 0

Proposal for coding standard update: Increase chars per line 80-> 128.

by Anton Komlev

Hi, TF-M coding standard<https://tf-m-user-guide.trustedfirmware.org/contributing/coding_guide.html> mandates up to 80 characters per line. This looks a bit too restrictive nowadays with no punch cards or text terminals. I propose to increase this limit to 120 or 140 characters. Personally like 128. Are there any thoughts or objections against it? Thanks, Anton

3 years, 4 months

6
7
0 0

Example Partition Updates

by Kevin Peng

Hi all, Please be noted that the TF-M example Secure Partition has been moved from the tf-m-tools repo to the tf-m-extras<https://git.trustedfirmware.org/TF-M/tf-m-extras.git/tree/examples/example_…> repo. It has also been aligned with the latest TF-M. The documentations are improved as well. It could be a good reference for Secure Partition developer starters. Best Regards, Kevin

3 years, 4 months

2
2
0 0

Documentation improvements

by Anton Komlev

Hello, The project documentation will never be ideal and we are continuing improving it. Let me ask you for reply to this email with the pain points you have experienced or suggestions for improvements to be considered in this phase. Your direct contribution with docs articles will be much appreciated too. For example: TF-M debugging technics and experience would be very helpful. Thank you in advance, Anton

3 years, 4 months

3
3
0 0

TF-M CI build failures in master

by Andersson, Joakim

It looks like the TF-M CI has build failures in the master branch. The build log for tf-m-build-and-test has a lot of build errors: https://ci.trustedfirmware.org/blue/organizations/jenkins/tf-m-build-and-te… The following message is printed: [2022-08-01T11:14:49.204Z] Exception: Invalid "conditional" attribute: "TEST_NS_CORE" for TFM Core Test Service. Please set to one of ['on', 'true', 'enabled'] or ['off', 'false', 'disabled', ''], case-insensitive. [2022-08-01T11:14:49.204Z] CMake Error at tools/CMakeLists.txt:158 (message): [2022-08-01T11:14:49.204Z] File generation failed The top commit on master looks like a likely candidate for this problem: commit 56979ee5579dbb90bbf598af4c252259e5f20777 (tfm/master) Author: Kevin Peng kevin.peng(a)arm.com<mailto:kevin.peng@arm.com> Date: Thu May 12 12:11:31 2022 +0800 Tools: Pass build configurations through header file This patch adds a new configuration header file argument for the manifest tool. For example, this PR is triggering the issue: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/16110 Joakim Andersson | Senior R&D Engineer Trondheim, Norway nordicsemi.com<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nordic…> | devzone.nordicsemi.com<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevzone.n…> Facebook<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.faceb…> | LinkedIn<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linke…> | Twitter<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.c…> | YouTube<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtu…> | Instagram<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.insta…> [Nordic_logo_signature]<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nordic…>

3 years, 4 months

3
3
0 0

[RFC]Decoupling manifest tool with build system

by Kevin Peng

[Thread res-used, title renamed] Hi all, This is now happening - fully support non-CMake use of the manifest tool. Here is the patch: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15756 With this patch, the manifest tool takes build configurations from a config header file instead of replying on the build system. Please check the details in the patch. Any comments are welcome. Best Regards, Kevin -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Thursday, May 12, 2022 2:49 PM To: Kevin Peng <Kevin.Peng(a)arm.com>; Raef Coles <Raef.Coles(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: RE: Any usage of environment variables in manifest lists > If there are strong requirements on supporting the non-cmake usecase Yes, it is 😉 -----Original Message----- From: Kevin Peng via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, May 12, 2022 5:46 AM To: Kevin Peng <Kevin.Peng(a)arm.com>; Raef Coles <Raef.Coles(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Re: Any usage of environment variables in manifest lists Well, I think I figured out a way to decouple them. If there are strong requirements on supporting the non-cmake usecase, I can try to work it out. Best Regards, Kevin -----Original Message----- From: Kevin Peng via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, May 12, 2022 10:09 AM To: Raef Coles <Raef.Coles(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Re: Any usage of environment variables in manifest lists Yes. The manifest tool is now fully replying on CMake (it has been, since I introduced the conditional parsing of manifests around half a year ago). It needs to be aware of the build configurations. Best Regards, Kevin -----Original Message----- From: Raef Coles <Raef.Coles(a)arm.com> Sent: Wednesday, May 11, 2022 7:15 PM To: tf-m(a)lists.trustedfirmware.org; Kevin Peng <Kevin.Peng(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: Any usage of environment variables in manifest lists Hey Kevin Does this mean that cmake will be required to generate the headers/etc from the manifests? I believe in the past we deliberately supported the non-cmake usecase, as some people were building TF-M in alternate ways. Raef ________________________________________ From: Kevin Peng via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 11 May 2022 09:24 To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [TF-M] Any usage of environment variables in manifest lists Hi, Is there anyone using environment variables for the "manifest" attribute in out-of-tree manifest lists? I'm asking because I'm working to support configurable stack_size for Secure Partitions<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>. In the patch the support of environment variables in manifest lists is removed<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>. Because I have to call the CMake command configure_file to replace the stack_size symbols (CMake variables<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> surrounded with "@") with their values. While configure_file does not recognize environment variables. If you do have environment variables in manifest list, there is an alternative: Replace the env. variables with CMake variables surrounded with "@" and set the value of the CMake variables in either config files or command line inputs. Best Regards, Kevin -- TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org -- TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org

3 years, 4 months

1
1
0 0

Intended use of psa_reset_key_attributes()

by S Krishnan, Archanaa

Hi, What was the intended usage of psa_reset_key_attribute(*attributes) which requires a PSA call from non-secure side to reset the client attributes? I am curious because the attributes to be reset comes from the non-secure memory, not directly associated with ITS/PS. The current IPC setup performs a PSA call to tfm_crypto_rest_key_attributes()(https://git.trustedfirmware.org/TF-M/trust… This function creates a copy of client key attribute in a secure key attribute structure. The secure key attribute is reset (set to 0) and then copied back to the client key attribute before returning to non-secure code. At first glance, this seems like a roundabout way to zeorise client side attributes. Regards, Archanaa

3 years, 4 months

2
3
0 0

FW: [Tf-openci-triage] [Maintenance] - ci.staging.trustedfirmware.org down time 2022-07-22

by Xinyu Zhang

Hi All, FYI. Open CI will be down from 2022 07-22 18:00 UTC to 2022-07-22 22:00 UTC for Jenkins upgrade. Please let us know if there is any problem. Thanks Xinyu -----Original Message----- From: Kelley Spoon via Tf-openci-triage <tf-openci-triage(a)lists.trustedfirmware.org> Sent: Thursday, July 21, 2022 10:14 PM To: tf-openci(a)lists.trustedfirmware.org; tf-openci-triage(a)lists.trustedfirmware.org Subject: [Tf-openci-triage] [Maintenance] - ci.staging.trustedfirmware.org down time 2022-07-22 Hello All, The server will be offline to start a maintenance window on 2022-07-22 at 20:00 UTC. Jenkins will be put into "Shutdown Mode" at 2022-07-22 18:00 UTC to stop accepting new jobs and allow executing tasks to complete. This downtime is required to add a plugin to Jenkins to support new functionality required for a service being developed. The version of Jenkins and the plugins currently being run will not be changing. Emails will be sent prior to and following the upgrade to provide status reports. Start: 2022 07-22 18:00 UTC End: 2022-07-22 22:00 UTC Regards, -- Kelley Spoon <kelley.spoon(a)linaro.org> -- Tf-openci-triage mailing list -- tf-openci-triage(a)lists.trustedfirmware.org To unsubscribe send an email to tf-openci-triage-leave(a)lists.trustedfirmware.org

3 years, 5 months

1
0
0 0

ns_agent flag

by Chris.Brand＠infineon.com

In https://lists.trustedfirmware.org/archives/list/tf-m@lists.trustedfirmware.… Ken mentions the need for a special flag in the manifest to indicate a non-secure agent partition. The code change is fairly easy, I think, but the manifest file format is specified by PSA, and presumably would also need to change. How do we go about doing that? Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> International Place 13700 V6V 2X8 Richmond Canada www.infineon.com<www.cypress.com> www.cypress.com<http://www.cypress.com> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies> Part of your life. Part of tomorrow. NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.

3 years, 5 months

2
1
0 0

Last call for comments on patch 15362

by Chris.Brand＠infineon.com

Hi, We'd like to merge https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15362 which makes a small modification to all platform configs (TFM_CONFIG_USE_TRUSTZONE and TFM_MULTI_CORE_TOPOLOGY lose their default values and must be specified for every platform). Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> International Place 13700 V6V 2X8 Richmond Canada www.infineon.com<www.cypress.com> www.cypress.com<http://www.cypress.com> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies> Part of your life. Part of tomorrow. NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.

3 years, 5 months

1
0
0 0

Re: [TF-A] Re: Rebooting LTS discussion

by Varun Wadekar

Hi Everyone, We presented a proposal at the Tech Forum yesterday to take the LTS idea forward. The recording link and password are provided below. This effort is important for the project, and we don't want to rush into something that is not useful. With holidays and other engagements, we want to provide more time to digest the information and provide feedback. We will schedule another Tech forum discussion in September to hear feedback/concerns/questions. See you soon! -Varun Recording: https://linaro-org.zoom.us/rec/share/wYFz4jQvpLZntYSamyjc5-n_bGNcx_RFm-amEd… Passcode: NUx82^W= From: Joanna Farley <Joanna.Farley(a)arm.com> Sent: Wednesday, 22 June 2022 3:05 PM To: Varun Wadekar <vwadekar(a)nvidia.com>; Okash Khawaja <okash(a)google.com> Cc: Matteo Carlini <Matteo.Carlini(a)arm.com>; tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Re: Rebooting LTS discussion External email: Use caution opening links or attachments Hi Everyone, I learnt today that our peer project (TF-M) are having a similar LTS discussion and have their own LTS Tech forum session tomorrow. Its an 8am BST(GMT+1) meeting start but I'm told the LTS discussion is mid agenda so expect the discussion on that to start around 8:30am. I'm told it's an information gathering session rather than a proposal session. Anyway the Zoom id of the call is below. These are recorded like TF-A sessions and will be uploaded to their Techforum page. Joanna This event has been changed with this note: "Extending end date" TF-M Tech forum When Changed: Every 4 weeks from 12am to 1am on Thursday Mountain Standard Time - Phoenix Where https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT…<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flinaro-or…> (map<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.googl…>) Calendar anton.komlev(a)arm.com<mailto:anton.komlev@arm.com> Who * Don Harbin - creator * tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> * anton.komlev(a)arm.com<mailto:anton.komlev@arm.com> * leonardo.sandoval(a)linaro.org<mailto:leonardo.sandoval@linaro.org> * abdelmalek.omar1(a)gmail.com<mailto:abdelmalek.omar1@gmail.com> more details ><https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcalendar.…> 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/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.googl…> ====Zoom==== Topic: TF-M Tech forum - Asia Time Zone Friendly Time: 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 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJYodOyvpz8jGNEc_1ykVap8Zg6oTLqZZSeJ/ics…<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.googl…> Join Zoom Meeting https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT…<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.googl…> Meeting ID: 925 3579 4925 Passcode: 414410 One 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-free Meeting ID: 925 3579 4925 Find your local number: https://linaro-org.zoom.us/u/aesS64I7GW<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.googl…> Going (anton.komlev(a)arm.com<mailto:anton.komlev@arm.com>)? All events in this series: Yes<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcalendar.…> - Maybe<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcalendar.…> - No<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcalendar.…> more options ><https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcalendar.…> Invitation from Google Calendar<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcalendar.…> You are receiving this courtesy email at the account anton.komlev(a)arm.com<mailto:anton.komlev@arm.com> because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcalendar.…> and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.g…>. From: Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>> Date: Tuesday, 21 June 2022 at 18:11 To: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>>, Okash Khawaja <okash(a)google.com<mailto:okash@google.com>> Cc: Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>>, tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] Re: Rebooting LTS discussion Thanks Varun and Okash. I'll update Jul 14th invite and add LTS as the discussion area. From: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Date: Tuesday, 21 June 2022 at 17:24 To: Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>>, Okash Khawaja <okash(a)google.com<mailto:okash@google.com>> Cc: Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>>, tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: RE: [TF-A] Re: Rebooting LTS discussion Hi Joanna, Thanks for the update. Okash and I would be ready by July 14. We will prepare the slides for the session. -Varun From: Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>> Sent: Tuesday, 21 June 2022 5:07 PM To: Okash Khawaja <okash(a)google.com<mailto:okash@google.com>>; Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Cc: Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: Re: [TF-A] Re: Rebooting LTS discussion External email: Use caution opening links or attachments Okash, Varun, Any thoughts when you want to do a LTS TechForum session. 30th June is now taken and the next scheduled one after that is 14th July. We could try and do a special one on 7th July if that's better. I'm reliant on you guys to jointly prepare and present a LTS TF-A Tech forum session Joanna From: Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Date: Monday, 6 June 2022 at 13:47 To: Okash Khawaja <okash(a)google.com<mailto:okash@google.com>> Cc: Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>>, tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: [TF-A] Re: Rebooting LTS discussion Hi Okash, The next session after next week is Thursday 30th June at 4pm BST. This is also available with nothing currently scheduled. Joanna From: Okash Khawaja <okash(a)google.com<mailto:okash@google.com>> Date: Monday, 6 June 2022 at 13:34 To: Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>> Cc: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>>, Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>>, tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] Re: Rebooting LTS discussion Hi Joanna and Varun, Sounds good to me. I will be out of country during next week. After that should be fine. Thanks, Okash On Mon, Jun 6, 2022 at 12:13 PM Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>> wrote: Varun, Okash, I believe the two of you have some interest in the LTS topic. Would the two of you be willing to jointly prepare and present a TF-A Tech forum session? The next available session is Thursday 16th June at 4pm BST. I'm sure there are many definitions of what a LTS release branch is in terms of purpose, content, duration etc. I would expect many platform providers are doing this downstream today and I could imagine there may be variations. Some degree of consensus on how this is managed and resourced would be needed I believe between multiple platform providers who would want to consume this. It would be good to see issues raised for discussion. I'm happy to host if the two of you and any other platform providers interested can prepare a TF-A session to present to the broader TF-A community. Thanks Joanna From: Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Date: Tuesday, 31 May 2022 at 15:23 To: Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>>, Okash Khawaja <okash(a)google.com<mailto:okash@google.com>>, tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: [TF-A] Re: Rebooting LTS discussion Hi Matteo/Okash, Thanks for re-starting the discussion. We (NVIDIA) are still interested in the idea and would like to discuss the next steps. I like the idea of a hotfix release, although would propose back-porting fixes to more tags. A targeted tech forum or another mechanism works for me. I would like to discuss the scope of the activity and the engagement model. -Varun -----Original Message----- From: Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>> Sent: Tuesday, 17 May 2022 3:39 PM To: Okash Khawaja <okash(a)google.com<mailto:okash@google.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Cc: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>>; raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com> Subject: RE: [TF-A] Rebooting LTS discussion External email: Use caution opening links or attachments Hi Okash, Thanks for rebooting the conversation. Out of the brainstorming from 1.5 yrs ago, we had this page published with an initial RFC proposal for LTSs: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper…<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper…> Worth mentioning that, in the meanwhile, the TF-M project has introduced the concept of Hotfix releases (which is a very lightweight process for backporting critical bug fix/security fixes only to the last available tagged release): https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftf-m-user…<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftf-m-user…> I'm curious to hear others' opinion and interest (@Varun, @Raghu ?) to possibly revive this topic in either in a Tech Forum or at a project TSC/Board level. Thanks Matteo -- TF-A mailing list -- tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> To unsubscribe send an email to tf-a-leave(a)lists.trustedfirmware.org<mailto:tf-a-leave@lists.trustedfirmware.org>

3 years, 5 months

2
1
0 0

Partition priority questions

by Bohdan.Hunko＠infineon.com

Hi everyone, TFM manifest files allow to specify priority for the partition. FFM 1.0 and FFM 1.1 specify that there are 3 possible values for this field: Low, NORMAL, HIGH. This field is used in several template files to generate needed for SPM information. From what I see there are several problems with current implementation: 1. In secure_fw/spm/cmsis_func/tfm_spm_db_func.inc.template priority field is used to generate .partition_priority filed of spm_partition_static_data_t structure. It uses TFM_PRIORITY() macro to convert priority to numeric value. The problem is that this field is actually never used, instead all priority checking is done using .flags field of partition_{{manifest.name|lower}}_load_info_t structure (tools/templates/partition_load_info.template file). 2. .flags field uses PARTITION_PRI_ macro to convert priority to numeric value. Possible values for TFM_PRIORITY() are: LOW, NORMAL, HIGH, but PARTITION_PRI_ macro has: LOWES, LOW, NORMAL, HIGH, HIGHEST priorities. More over priorities with same names for these 2 macros have different numeric values (e.g. PARTITION_PRI_LOW is 0x7F while TFM_PRIORITY_LOW is 0xFF) 3. Scatter files does not account for HIGHEST priority (see code here<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…>). This is a problem for all toolchains including both common scatter files (L1 and L2) and scatter files templates for L3 So I have several questions on this topic: 1. Are LOWEST and HIGHEST priorities system reserved? Because for now they cant be used in manifest files as TFM_PRIORITY() does not have support them. 2. Should TFM_PRIORITY() macro and .partition_priority filed of spm_partition_static_data_t structure be removed? This will mean that if LOWEST and HIGHEST priorities are system reserved then validation of value for "priority" manifest field should be added to tfm_parse_manifest_list.py 3. Should scatter files be fixed to account for HIGHEST priority? 4. secure_fw/partitions/ns_agent_tz/load_info_ns_agent_tz.c for NS agent TZ specifies (PARTITION_PRI_LOWEST - 1) for a .flags filed. Higher priority numeric values is lower real priority, which means that TZ NS agent partition priority is between LOW and LOWEST priority. This seems like a hack to me, maybe we should introduce One more named priority? 5. In secure_fw/partitions/CMakeLists.txt idle partition is included when IPC backend is used. Idle partition is used to retrigger scheduling before going into WFI state (just to be sure that higher priority partitions were executed and there is not pending request). I can see how this partition is useful for MULTICORE case, to have kind of sleep state. But for TZ case TZ ns agent is always RUNNABLE and have higher priority that IDLE partition so it does not look like IDLE partition will ever be scheduled in TZ case. In such case condition in this Cmake file should be changed from "if (CONFIG_TFM_SPM_BACKEND_IPC)" to "if (TFM_PARTITION_NS_AGENT_MAILBOX)" Am I wrong somewhere? Sorry, I know that is a lot of questions, but this scheduling stuff is really hard to wrap a head around. 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 years, 5 months

2
2
0 0

PSA arch test problem

by Bohdan.Hunko＠infineon.com

Hi, Lately I have been working with PSA arch tests and found few issues with them: 1. PSA arch tests build on Windows fails. I am using the following command: cmake -S . -B build_gcc_psoc64 -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DTEST_PSA_API=INITIAL_ATTESTATION This is true for all the compilers and build types. I have also tried building Musca B1 and the results are the same. Is this expected behavior? Are PSA arch test meant to be built on windows? 2. I have tried building PSA arch tests with IAR on both Linux and Windows and it does not work. From quick investigation it looks like IAR is not supported. Am I right? And if so the is there a plan to support PSA arch tests for IAR compiler? 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 years, 5 months

6
15
0 0

Proposal for Musca-B1 SE deprecation

by Anton Komlev

Hello, We would like to propose removing the Musca-B1 Secure Enclave platform configuration* in TF-M. This solution was developed to demonstrate the PSA Configuration to support the TF-M Secure Services on Secure Enclave providing Secure Services to the Host processor running non-secure application. Musca-B1 SE was the foundation of the Corstone-1000** solution, which provides a secure enclave implementation that is also PSA L2 Ready Certified. Please reply if there are any concerns deprecating and removing the Musca-B1 SE configuration from TF-M . Process for deprecation and removal of platforms can be found here https://tf-m-user-guide.trustedfirmware.org/platform/ext/platform_deprecati… * https://tf-m-user-guide.trustedfirmware.org/platform/ext/target/arm/musca_b… ** https://tf-m-user-guide.trustedfirmware.org/platform/ext/target/arm/corston… Thanks, Anton

3 years, 5 months

1
1
0 0

Manifest files questions

by Bohdan.Hunko＠infineon.com

Hi everyone, I have several questions related to manifest files in TFM: 1. Currently TFM dos not support dynamic memory allocation, so heap_size manifest field is a bit special. Presence of heap_size field for library model will generate error in tfm_spm_db_func.inc.template but when TFM_PSA_API is ON heap_size is used in partition_load_info.template which will silently set .heap_size struct field to 0 without generation of any error. As dynamic memory allocation is not supported I think error should be generated in both files. Also I think that error should only be generated if heap_size filed is present and is not "0" (if it is not present or is 0 then no error should be generated because it is compliant with "no dynamic memory rule") 2. Manifest files support numbered mmio regions for partitions. Example "mmio_regions": [ { "base": "MY_CUSTOM_REGION_BASE", "size": "MY_CUSTOM_REGION_SIZE", "permission": "READ-WRITE" } ] The questions is why doesn't TFM use this field for ITS and PS areas instead of handling them manually? Can this be reworked to use mmio regions? If so then is this work planned and when approximately it will be done? 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 years, 5 months

2
1
0 0

Library fetching improvements

by Bohdan.Hunko＠infineon.com

Hi, Recently I have been adding some new libraries to my TFM project and what I always end up doing is: go to some existing file which fetches the library, copy code from there, paste it to my file, change few links, versions and names. It is a bit annoying to copy-paste that code each time, also it is hard to maintain (if pattern for fetching libraries changes) and also copy pasting might lead to some code not being updated. My proposal is to have a function that can be used to fetch a library. This way it will be easier to add new libraries and this change will make code cleaner. Please let me know your thoughts on this proposal. 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 years, 5 months

5
8
0 0

Automatically copy RAM_VECTORS when using ARMClang and IAR

by Bohdan.Hunko＠infineon.com

Hi, When poking around some startup files I have found interesting place related to RAM_VECTORS support CMSIS have __PROGRAM_START macro which is different for each compiler. For GCC it uses __cmsis_start, for ARMClang - __main and for IAR - __iar_program_start Basically each of the functions should copy several sections (.TFM_DATA for example) from FLASH to RAM and zero out some parts of RAM (for .TFM_BSS for example) In current implementation GCC __cmsis_start function also copies the vector table from FLASH to SRAM (if RAM_VECTORS are enabled) But ARMClang and IAR equivalents of that function (__main, __iar_program_start) does not seem to take care of copying vector table, so platforms startup should do that I wonder if there is a way to change linker script in a way which will make copying of vector table automatic (by compiler dependent function). This will make platform startups a bit cleaner and will allow platform to just use __PROGRAM_START macro without any additional code to copy vector table. From what I see IAR has "initialize by copy" syntaxis so I think it may be used to tell IAR to automatically copy vector table. It is a bit more tricky with ARMClang as I have not found a way to do that there. I am not a big expert in ARMClang and IAR so maybe someone may help me here, give some directions or confirm that currently there is no way to make this idea work. Basically the intention is to simplify platform startup code and offload common operations to compiler specific platform independent functions. 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 years, 5 months

2
5
0 0

FW: [Tf-openci] [Maintenance] - ci.trustedfirmware.org down time 2022-07-08

by Xinyu Zhang

Hi All, FYI. Open CI will be down from 2022-07-07 23:00 UTC to 2022-07-08 03:00 UTC for Jenkins upgrade. Please let us know if there is any problem. Thanks Xinyu -----Original Message----- From: Kelley Spoon via Tf-openci <tf-openci(a)lists.trustedfirmware.org> Sent: Wednesday, July 6, 2022 2:02 PM To: tf-openci(a)lists.trustedfirmware.org; tf-openci-triage(a)lists.trustedfirmware.org Subject: [Tf-openci] [Maintenance] - ci.trustedfirmware.org down time 2022-07-08 Hello All, The server will be offline to start a maintenance window on 2022-07-08 at 01:00 UTC. Jenkins will be put into "Shutdown Mode" at 2022-07-07 23:00 UTC to stop accepting new jobs and allow executing tasks to complete. This downtime is required to execute an upgrade to Jenkins 2.332.3. The upgrade will address several security advisories for Jenkins core and its plugins and will also bring the server to feature parity with staging. Emails will be sent prior to and following the upgrade to provide status reports. Start: 2022 07-08 01:00 UTC End: 2022-07-08 03:00 UTC Regards, -- Kelley Spoon <kelley.spoon(a)linaro.org> -- Tf-openci mailing list -- tf-openci(a)lists.trustedfirmware.org To unsubscribe send an email to tf-openci-leave(a)lists.trustedfirmware.org

3 years, 5 months

1
0
0 0

Ask for review on TF-M memory check interface update patch

by Summer Qin

Hi, I have sorted out memory check functions and done some refinement. As it covers all the platforms, may I ask for a review on these patches<https://review.trustedfirmware.org/q/topic:%22memory-check-interface-update…>? I would like to merge it by 30th of this month if possible. Thanks so much! Best Regards, Summer

3 years, 5 months

1
0
0 0

PS partition dependencies

by Chris.Brand＠infineon.com

I'm experimenting with a build with the SFN backend, and I've hit an error. cmake -S . -B build_musca_sse200_GNUARM_Release -DTFM_PLATFORM=arm/musca_b1/sse_200 -DCONFIG_TFM_SPM_BACKEND=SFN -DTFM_PARTITION_PLATFORM=OFF -DTFM_PARTITION_FIRMWARE_UPDATE=OFF -DPS_ROLLBACK_PROTECTION=OFF cmake --build build_musca_sse200_GNUARM_Release results in .../build_musca_sse200_GNUARM_Release/generated/secure_fw/partitions/protected_storage/auto_generated/load_info_tfm_protected_storage.c:85:9: error: 'TFM_SP_PLATFORM_NV_COUNTER_SID' undeclared here (not in a function); did you mean 'TFM_SP_NON_SECURE_ID'? TFM_SP_PLATFORM_NV_COUNTER_SID, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ TFM_SP_NON_SECURE_ID Config/check_config.cmake line 93 is tfm_invalid_config((TFM_PARTITION_PROTECTED_STORAGE AND PS_ROLLBACK_PROTECTION) AND NOT TFM_PARTITION_PLATFORM) but secure_fw/partitions/protected_storage/tfm_protected_storage.yaml lists TFM_SP_PLATFORM_NV_COUNTER as a dependency unconditionally. The easy fix is to change check_config.cmake to have the PS partition unconditionally require the platform partition, but it seems that the intent is that it should still be possible to enable PS without rollback protection. Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> International Place 13700 V6V 2X8 Richmond Canada www.infineon.com<www.cypress.com> www.cypress.com<http://www.cypress.com> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies> Part of your life. Part of tomorrow. NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.

3 years, 5 months

2
1
0 0

Ask for review on TF-M patch

by Sherry Zhang

Hi, I have created a patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15313/> which removes the unnecessary heap(including the RAM memory reserved for heap and the heap related symbols). As it covers all the platforms and compilers, may I ask for a review on this patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15313/>? This patch saves about 680 bytes Flash while 4200 bytes RAM. I would like to merge it by 29th this month if possible. Thanks so much! Regards, Sherry Zhang

3 years, 5 months

1
0
0 0

Technical Forum call - June 23 - agenda

by Anton Komlev

Hello, the agenda for the forum tomorrow, June 23, 7:00-8:00 UTC 1. Proposal of External Trusted Secure Storage by Poppy Wu 2. Long Time Support (LTS) in TF-M project: the needs, cadence, scope. Open discussion. 3. AOB 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/ Thanks, Anton

3 years, 5 months

1
0
0 0

Technical Forum call - June 23

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, June 23, 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

3 years, 6 months

1
1
0 0

Re: Technical Forum call - June 23

by Edward Yang

Hi Anton, I'd like to give a presentation about the proposal of External Trusted Secure Storage, and the presentation will take about 30 minutes, thanks. Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 http://www.mxic.com.cn Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> 2022/06/15 20:31 Please respond to Anton Komlev <Anton.Komlev(a)arm.com> To "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> cc nd <nd(a)arm.com> Subject [TF-M] Technical Forum call - June 23 Hello, The next Technical Forum is planned on Thursday, June 23, 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 -- TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

3 years, 6 months

1
0
0 0

Migrate to Mbed TLS PSA configuration scheme

by Summer Qin

Hi, TF-M is going to migrate to Mbed TLS PSA configuration scheme which is recommended by Mbed TLS. With this new feature, TF-M is able to: * more conveniently to align and check TF-M Crypto feature setting against Mbed TLS configuration. * enable the HW crypto accelerator to use PSA drivers and get rid of Mbed TLS software implementation. Therefore, it can decrease the Crypto SW code size for HW accelerator. After migrating to Mbed TLS PSA configuration scheme, TF-M ROM size will save about 6.5kB. The general mbedtls-psa-configuration<https://review.trustedfirmware.org/q/topic:%22mbedtls-psa-configuration%22+…> patches are going to be merged soon. While the HW crypto patch is still under platform owner review until this Friday. It is welcome that if you have any comments and suggestions : ) Best Regards, Summer

3 years, 6 months

1
0
0 0

Refining TF-M contribution processes

by David Hu

Hi all, I'm refining TF-M contribution processes. Hope it can better support you to contribute to TF-M community. Currently I focus on the following two repos: * Tf-m-extras: specify the tf-m-extras additional requirements. Enable contributor to specify the maintainers. Patch link<https://review.trustedfirmware.org/c/TF-M/tf-m-extras/+/15430>. * Trusted firmware-m: simplify the contribution process a bit to align with current development practices. Make it as a general process reference for other TF-M repos. Patch link<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15472>. Can I ask your to take a look at those changes to the processes? Please let us know if any step can be optimized/clarified further. Any feedback is welcome. Best regards, Hu Ziji

3 years, 6 months

1
0
0 0

TF-M documentation integration

by Anton Komlev

Hello, TF-M documentation reflects the documents in the main TF-M repository (https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs) only. There are 5 other repos (tests, tools, extras, CI) with corresponded docs being good to be linked to the main. Looking for ideas / advice on the best way to do that. The main problem is that Sphinx (the documentation tool) renders files under its configuration directory only, ignoring everything outside of it so reference to external repos is not an easy task. I see several solutions: 1. The main doc points to external files (*.rst) as an external link without rendering it. Like this<https://git.trustedfirmware.org/TF-M/tf-m-tools.git/tree/depend-trace-tool/…>. <-- Simplest way. 2. Create Sphinx doc for each repository, store rendered output in a temporal storage and link the main to generated HTML files. 3. Use intersphinx<https://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html> to link across repositories. Again, need rendered docs in each repo and additional preparation. 4. Anything else? Any thoughts or experience to share? Thanks in advance, Anton

3 years, 6 months

2
3
0 0

Technical Forum call - June 9

by Anton Komlev

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

3 years, 6 months

1
1
0 0

Mis-use of tfm_spm_partition_set_state()

by Chris.Brand＠infineon.com

Looking at the declaration and body of this function, the first parameter is clearly a partition index (index into g_spm_partition_db.partitions[]), and all the call sites in secure_fw/spm/cmsis_func/spm_func.c use it that way. The three call sites in secure_fw/spm/cmsis_func/main.c, though, all pass a PID instead. This happens to work because g_spm_partition_db.partitions[0].static_data->partition_id == 0 and g_spm_partition_db.partitions[1].static_data->partition_id == 1. I don't see anything that guarantees that that will always be true, though. There is a static function get_partition_id() in secure_fw/spm/cmsis_func/spm_func.c that maps from PID to partition index - should that be exported and called to address this? Thanks, Chris Brand .

3 years, 6 months

2
2
0 0

Mailbox agent redesign

by Chris.Brand＠infineon.com

Hi, Reading https://tf-m-user-guide.trustedfirmware.org/technical_references/design_doc… it mentions the plan to move ns_agent_mailbox to have "a positive valued Partition ID in the manifest" and it also states that "A standard Secure Partition gets errors when calling the Extended API". Given that it will not possible to use the PID to identify the ns_agent_mailbox, how will the Extended API functions know whether the caller is a standard Secure Partition or not? There was a patch https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15142 that introduced a flag to identify the ns_agent_tz partition - would this be similar? Also, is there a plan for which release this functionality is expected to appear? Thanks, Chris Brand

3 years, 6 months

2
1
0 0

Usage of TFM_SYSTEM_FP cmake variable

by Bohdan.Hunko＠infineon.com

Hi everyone, I have noticed that GCC toolchain uses CONFIG_TFM_FP to determine FP setting while IAR and Clang use TFM_SYSTEM_FP cmake variable. I was not able to find any docs on this variable, and also there is no assignment of this variable in TFM source code (only read operation from this variable). Is this intendent behavior? 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 years, 6 months

2
4
0 0

psa_connect() return invalid connect handle error

by Edward Yang

Hi experts, We are developing a demo based on TF-M framework, and we also developed an application RoT partition SP1 and a PSA RoT partition SP2. The secure partition SP1 needs calling a SP2's service during SP1's init(), when the SP1_init() calls a SP2 service, as the SP2 partition hasn't been inited, the SP2_init() executes before handling requestS from SP1. But the returned connect handle is an invalid handle, return PSA_ERROR_GENERIC_ERROR. I am wondering why an invalid connect handle is returned? Any hints? Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 http://www.mxic.com.cn ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

3 years, 6 months

2
1
0 0

Non-secure use of NMI

by Andersson, Joakim

Hi. I was looking into a failing test-case in the Zephyr project for the NMI not being processed when using TF-M. The issue is that SCB.AIRCR.BFHFNMINS bit is not set, so the non-secure write to SCB.ICSR.NMIPENDSET is ignored. Is this a decision that was explicitly made for the TF-M configuration to not allow the non-secure application to use the NMI handler? I could not find anything in the TF-M documentation mentioning the NMI. Are there security concerns related to the NMI? Joakim Andersson | Senior R&D Engineer Trondheim, Norway nordicsemi.com<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nordic…> | devzone.nordicsemi.com<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevzone.n…> Facebook<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.faceb…> | LinkedIn<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linke…> | Twitter<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.c…> | YouTube<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtu…> | Instagram<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.insta…> [Nordic_logo_signature]<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nordic…>

3 years, 6 months

2
1
0 0

Technical Forum call - May 26

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, May 26, 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 years, 6 months

1
1
0 0

tfm_arch_is_priv() is not available for v8arch

by Bohdan.Hunko＠infineon.com

Hi everyone, While looking through TFM code I have noticed that tfm_arch_is_priv() is defined for v6 and v7 in secure_fw/spm/cmsis_psa/arch/tfm_arch_v6m_v7m.h but not defined for v8. Also tfm_arch_v6m_v7m.h is located in secure_fw/spm/cmsis_psa/arch/ folder, while tfm_arch_v8m.h is located in secure_fw/spm/include/. I think that tfm_arch_is_priv() should also be defined for v8 and also tfm_arch_v6m_v7m.h should be moved to secure_fw/spm/include/. If file will be moved then we can clean up some target_include_directories() which used secure_fw/spm/cmsis_psa/arch/ folder. Any thoughts on this? Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

3 years, 6 months

2
1
0 0

Re: Enable SPI interrupt in secure partition

by Edward Yang

Hi Kevin, Thanks for your instruction. We're developing an application RoT partition which access a sensor via an SPI interface(Based on RA6M4_EK development board). After commands have been transferred to the sensor, an SPI_TX_INTERRUPT should be triggered, then calls spi_tx_isr(). Now let's put aside binding secure interrupts to each secure partition, just talk about how to enable SPI interrupts in secure world simply. Here is my implementation: 1.Configure this SPI peripheral as secure peripheral. 2.Assign SPI tx and rx interrupts to secure state by setting NVIC->ITNS register. 3.Enable SPI tx and rx interrupts by seeting NVIC->ISER register. But during debug, I found that spi0_tx_isr() (The ISRs are also placed under this application RoT partition's folder) has never been triggered. Is there anything that I miss? Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 http://www.mxic.com.cn Kevin Peng via TF-M <tf-m(a)lists.trustedfirmware.org> 2022/05/17 09:45 Please respond to Kevin Peng <Kevin.Peng(a)arm.com> To Edward Yang <EdwardYang(a)mxic.com.cn>, "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> cc Subject [TF-M] Re: Enable SPI interrupt in secure partition Hi Poppy, First-Level Interrupt Handling (FLIH) should be recommended in your use case as you have latency requirements. Here is an example: https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/test/secure_fw/sui… You’ll firstly need to add an “irq” item in the manifest and “handling ” it with “FLIH”: https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/test/secure_fw/sui… And also add the “mmio_regions” item with the associated device (SPI) to give access permissions to the Secure Partition. The IRQ handling should be in the Secure Partition: https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/test/secure_fw/sui… Note that, no PSA APIs are allowed in the handling. Best Regards, Kevin From: Edward Yang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Monday, May 16, 2022 5:38 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Enable SPI interrupt in secure partition Hi experts, Recently we're developing a demo based on TF-M, this demo involves using SPI module to drive a sensor by sending commands in a secure partition. And we need to enable SPI receive and send interrupt in this secure partition and the latency shall be as small as possible. I am wondering how to implement this secure interrupts. Is there any example code or instrucstions? Thanks. Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 http://www.mxic.com.cn CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================-- TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

3 years, 7 months

2
1
0 0

Enable SPI interrupt in secure partition

by Edward Yang

Hi experts, Recently we're developing a demo based on TF-M, this demo involves using SPI module to drive a sensor by sending commands in a secure partition. And we need to enable SPI receive and send interrupt in this secure partition and the latency shall be as small as possible. I am wondering how to implement this secure interrupts. Is there any example code or instrucstions? Thanks. Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 http://www.mxic.com.cn ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

3 years, 7 months

2
1
0 0

'memset/memcpy/mem*' API usage in secure firmware

by Ken Liu

Hi TF-Mers, There are several versions of mem* API set in the system. At the very beginning, the whole secure firmware was put in the library model, and it is expected to be self-contained -- at least at the source level as the first step. Hence a 'tfm_mem*' API set is created for secure firmware usage. The same reason for involving 'spm_mem*' in the PSA compliance model. When we designed HAL for SPM, we noticed that SPM HAL actually run in the same domain as SPM, hence we encouraged developers to use 'spm_mem*' in SPM HAL. This brings a bit of difficulty, especially when the platform sources are shared for multiple targets, while other targets do not have 'spm_mem*' API. As 'mem*' is actually common enough (as they are fundamental API of libc), hence redefine the name is applicable only a system is highly self-contained. In our case, using 'mem*' API can bring much convenience. Hence I am thinking to let sources other than SPM use 'mem*' API, they are platform, partitions and runtime libraries. For SPM sources (under secure_fw/spm), a source-level 'spm_mem*' is kept, to keep the possibility to make SPM itself really self-contained. Now it is only source-level because 'spm_mem*' is actually forwarded to 'mem*'. I am creating a patch to change this, and want to know your opinion. Thanks. /Ken

3 years, 7 months

1
0
0 0

Any usage of environment variables in manifest lists

by Kevin Peng

Hi, Is there anyone using environment variables for the "manifest" attribute in out-of-tree manifest lists? I'm asking because I'm working to support configurable stack_size for Secure Partitions<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15155>. In the patch the support of environment variables in manifest lists is removed<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15155/1/tool…>. Because I have to call the CMake command configure_file to replace the stack_size symbols (CMake variables<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15155/1/secu…> surrounded with "@") with their values. While configure_file does not recognize environment variables. If you do have environment variables in manifest list, there is an alternative: Replace the env. variables with CMake variables surrounded with "@" and set the value of the CMake variables in either config files or command line inputs. Best Regards, Kevin

3 years, 7 months

3
5
0 0

Re: Technical Forum call - May 12 Cancelled

by David Hu

Hi all, I'd like to cancel tech form in May 12 due to empty agenda. Best regards, Hu Ziji From: David Hu via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, May 5, 2022 2:11 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - May 12 Hi, (On behalf of Anton) The next Technical Forum is planned on Thursday, May 12, 15:00-16:00 UTC (West 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, Hu Ziji

3 years, 7 months

1
0
0 0

Attestation token new spec

by Tamas Ban

Hi, the initial attestation token implementation is aligned with this specification: https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-05 This spec is still evolving and there is a newer version which changes the key values of the claims in the token: https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#tab…<https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html%23t…> This can cause combability issues between token issuer (device) and token verifier (some remote verification service). This is an ABI change between token issuer and consumer. The breaking effect would be manifest in unaccepted IAT tokens by the verifier. On-device side I see these options to make the transition: - A build-time option could be introduced which determines which range of key numbers to use. The default value would be the new range. To not let new users pick up the old values accidentally. Existing users can notice the incompatibility issue during the integration test and adjust their build command accordingly. However, the old range would be announced as deprecated in the next TF-M release, then will be removed in the next release after. - Immediate switch over to the new range, without supporting the old range anymore. On the verification service side, an SW update can handle the transition and might be accepting both ranges for a while. I assume the verification service can be updated more easily than remote devices therefore better to handle the compatibility issue there. - Keeping the support for both ranges for the long term and letting users choose by build time. Please share your thoughts on: - Are you aware that the attestation service is used in deployed devices where this transition can cause incompatibility? - From the above list which option would you vote to support the transition? Best regards, Tamas Ban

3 years, 7 months

1
0
0 0

Under-layer runtime functions in assembly

by Ken Liu

Hi, In one of the past tech forums, we claimed that we don't encourage contribution in common logic in assembly, and one of the patches was abandoned because of this. That patch is designed to improve the memset/memcpy performance. We override these APIs in general because we want the code can be auditable. Then we provided implementations in C, but it shows these implementation does not provide good performance. We want to apply the toolchain provided versions, and looks GNU tool provides the straightest 'byte-copy' version. And armclang involves unnecessary variants which increase the code size a little (not big). Hence we provide a version with 'tiny' optimization in assembly and mark this patch an exception to the review guidelines, as these under-layer functions won't get changed frequently. We are also seeking an ideal way to apply toolchain versions. The patch is here for your review: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/13735 Thanks. /Ken

3 years, 7 months

1
0
0 0

Supporting encryption with ITS

by Vasilakis, Georgios

Hello all, I wanted to let you know that I made the PR which adds encryption on ITS files using the methodology that we discussed before. The encryption is happening in a transparent way for the user, and I tried to avoid major changes in the ITS filesystem. Please add yourself as a reviewer and provide feedback if you think that this is an interesting use case for you. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15096 Regards, Georgios Vasilakis

3 years, 7 months

1
0
0 0

Technical Forum call - May 12

by David Hu

Hi, (On behalf of Anton) The next Technical Forum is planned on Thursday, May 12, 15:00-16:00 UTC (West 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, Hu Ziji

3 years, 7 months

1
0
0 0

TF-M v1.6.0 release

by Anton Komlev

Hello, I am pleased to announce the new v1.6.0 released of TF-M project. New major features are: * MCUboot updated to v1.9.0. * Mbed TLS updated to v3.1.0 (Support all required PSA Crypto APIs). * Enabled Secure Function (SFN) Model Partition compliance in IPC backend. * Interrupt support (both SLIH/FLIH) for the SFN backend. * MM-IOVEC Support for the SFN backend. * The following Secure Partitions are converted to SFN model: * Protected Storage * Internal Trusted Storage * Initial Attestation * FF-M v1.1 SFN Model supported in Profile Small. * HAL Separation of Library Model and IPC/SFN backend. * FP support for Armv8.1-M Mainline for IPC backend. * Simplified build output message and configurable output. * Halting instead of rebooting on panic in debug build type. * Automated testing of MCUboot BL2. * A new driver interface for the CC-312 runtime library as specified in the PSA Unified Driver spec [1]_. * Added reference bootloader stage 1 (BL1) bootloader for certain platforms. * A new CC312 ROM library for the BL1. * Updated documentation structure. The changes tagged by TF-Mv1.6.0 and located in the release/v1.6.x<https://review.trustedfirmware.org/q/project:TF-M%252Ftrusted-firmware-m+br…> branch at the moment. In short, they will be integrated with the main branch and be available from there. Thanks everyone for contribution, review and support this milestone. Anton

3 years, 7 months

1
0
0 0

Technical Forum call - April 28

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, April 28, 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 years, 7 months

1
1
0 0

Asking for review of external trusted secure storage partition implementation code

by Edward Yang

Hi everyone, We have discussed the design proposal of supporting secure Flash in tf-m framework via this mailing list before,now the implementation code of this external trusted secure storage partition has been uploaded to tf-m-extras repo for review： https://review.trustedfirmware.org/c/TF-M/tf-m-extras/+/14953 And the binary component of this patch has also been uploaded to tf-binaries repo： https://review.trustedfirmware.org/c/tf-binaries/+/14954 For easy understanding please refer to this document first: https://review.trustedfirmware.org/c/TF-M/tf-m-extras/+/14953/1/partitions/… Looking forward to your comments and suggestions. Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 http://www.mxic.com.cn ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

3 years, 7 months

1
0
0 0

Start of TF-M v1.6.0 release process

by Anton Komlev

Hello, The branch release/1.6.x<https://git.trustedfirmware.org/TF-M%2Ftrusted-firmware-m.git/log/?h=refs%2…> has been created, indicating the project feature's freeze and beginning the release process. Expecting to place RC1 tag asap, after successful run of the basic tests. Let me remind that the code is not frozen, and development can be continued on the main branch. Thanks, Anton

3 years, 8 months

1
4
0 0

TF-M Open CI Back to Normal

by Xinyu Zhang

Hi All, TF-M Open CI is back to normal now. Please feel free to use it. Thanks, Xinyu From: Xinyu Zhang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Monday, April 18, 2022 12:06 PM To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] TF-M Open CI Down Hi All, Sorry to inform you that TF-M Open CI is down for the time being because of Jenkins upgrade. I'll let you know once it is back to normal. Apologize for any inconvenience! Thanks, Xinyu

3 years, 8 months

1
0
0 0

TF-M Open CI Down

by Xinyu Zhang

Hi All, Sorry to inform you that TF-M Open CI is down for the time being because of Jenkins upgrade. I'll let you know once it is back to normal. Apologize for any inconvenience! Thanks, Xinyu

3 years, 8 months

1
0
0 0

Technical Forum call - April 14 is CANCELLED

by Anton Komlev

Hi, The forum is cancelled because of the empty agenda and the assumption that many of us in the west time zone will have a long weekend this week. Thanks, Anton From: Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Wednesday, April 6, 2022 12:43 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - April 14 Hi, The next Technical Forum is planned on Thursday, April 14, 15:00-16:00 UTC (West 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 years, 8 months

1
0
0 0

TF-M Isolation 3

by Doka.Dokanov-Dobrovolskyi＠infineon.com

Hello! My name is Oleg. I'm working on TF-M Isolation Level 3 testing and I need to develop test cases list for it. Could you be so kind to provide me the test cases list? May be you know where I can find it by myself? Also I have test cases list for Isolation Leve 2. Am I right that it can be reused for Isolation Level 3 with some changes? I will be very appreciate for any help. Thank you so much, Oleg Dokanov

3 years, 8 months

2
1
0 0

Technical Forum call - April 14

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, April 14, 15:00-16:00 UTC (West 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 years, 8 months

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M