- TF-M - lists.trustedfirmware.org

by Anton Komlev

Hi, Please be aware that the branch release/1.6.x<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/log/?h=release/…> is to be removed, following TF-M release process<https://tf-m-user-guide.trustedfirmware.org/releases/release_process.html#r…>. Please stop using it by the end of this week (Jan 13) or let me know if more time is necessary. The previous releases will be still available via tags like TF-Mv1.6.1<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tag/?h=TF-Mv1.6…> Thanks, Anton

2 years, 9 months

1
0
0 0

minor bug in an521 protections

by Bohdan.Hunko＠infineon.com

Hi, I have been working on TZ stuff recently and found small problem in an521 platform protections. The problem is in SAU config. sau_cfg in platform/ext/target/arm/mps2/an521/target_cfg.c has entry for NSPE code: { ((uint32_t)NS_PARTITION_START), ((uint32_t)NS_PARTITION_START + NS_PARTITION_SIZE - 1), false, }, Where both NS_PARTITION_START and NS_PARTITION_SIZE are 32 bytes aligned, which means that when 1 is subtracted lower 5 bits are getting set to 1, for example: 0x1000_0000 + 0x1000 - 1 = 0x10000FFF Then in sau_and_idau_cfg() function lower 5 bits are cleared by the mask: sau_cfg[i].RLAR & SAU_RLAR_LADDR_Msk This means that in reality highest 32 bytes of NSPE are protected as Secure in SAU. Same problem is present for SECONDARY_PARTITION_SIZE SAU entry. This is not huge problem, but still worth fixing. I believe other arm and TZ platforms may also have this bug, but I haven't checked 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>

2 years, 10 months

3
6
0 0

SAU region setting check request

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

2 years, 10 months

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

2 years, 10 months

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

2 years, 10 months

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

2 years, 11 months

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

2 years, 11 months

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>

2 years, 11 months

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

2 years, 11 months

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.

2 years, 11 months

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

2 years, 11 months

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

2 years, 11 months

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

2 years, 11 months

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.

2 years, 11 months

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

2 years, 11 months

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

2 years, 11 months

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

2 years, 11 months

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

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

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

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

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

2025

2024

2023

2022

2021

2020

2019

2018

TF-M